#324610 - 25/07/2009 21:00
Re: SSDs
[Re: mlord]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
1) upgrade to OCZ firmware 1.3 immediately, if not already on the unit.
2) ensure the drive is set for highest performance: hdparm -W1 -A1 /dev/sdX
All of that was set on the drive out of the box. 3) stop benchmarking, and just enjoy the speed! Yes, I will, but before these drives end up in their destined computers, I'd like to see where else they might make a difference, and where not. benchmarks generally show that the OCZ Vertex doesn't really take much advantage of it.
A performance drop of up to 60% isn't really an advantage indeed. Thanks, Pim
|
Top
|
|
|
|
#324616 - 26/07/2009 00:52
Re: SSDs
[Re: pim]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
OTOH.. the Data Set Management "Trim" command may be coming soon to the Indilinx drives, including the OCZ Vertex. There was a post to that effect on the OCZ BBS. Not that I might know anything further about such..
|
Top
|
|
|
|
#324621 - 26/07/2009 08:02
Re: SSDs
[Re: mlord]
|
carpal tunnel
Registered: 20/05/2001
Posts: 2616
Loc: Bruges, Belgium
|
Ah, that trimming command, is that to automatically 'zero' all the unused bits, so the SSD only had to do one action to change a bit? (and thus makes it faster?) I've read something about that, and for now you still need to run a dedicated command for that. So this will be implemented in the drive's firmware? Sweet!
_________________________
Riocar 80gig S/N : 010101580 red Riocar 80gig (010102106) - backup
|
Top
|
|
|
|
#324624 - 26/07/2009 11:52
Re: SSDs
[Re: BartDG]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
TRIM is simply a way for the operating system to tell the drive firmware about discarded sectors on the media.
So when one deletes a file, the O/S could issue some TRIM commands to inform the SSD firmware that the data in those sectors is no longer relevant.
The firmware can then use this knowledge to make more intelligent decisions about wear-leveling, garbage collection, and so forth.
Otherwise, without TRIM, the SSD firmware *must* assume that any sector that has *ever* been written to by sofware, still holds valid data. Forever. And cannot be erased/cycled without first copying the data elsewhere.
So TRIM is potentially a huge win for drive wear-leveling and overall performance.
Cheers
|
Top
|
|
|
|
#324629 - 26/07/2009 14:08
Re: SSDs
[Re: mlord]
|
carpal tunnel
Registered: 20/05/2001
Posts: 2616
Loc: Bruges, Belgium
|
Aha! I can see how this can indeed make a substantial difference! Thanks for the explanation Mark!
_________________________
Riocar 80gig S/N : 010101580 red Riocar 80gig (010102106) - backup
|
Top
|
|
|
|
#324644 - 26/07/2009 20:22
Re: SSDs -- unintended consequences
[Re: BartDG]
|
carpal tunnel
Registered: 17/12/2000
Posts: 2665
Loc: Manteca, California
|
So if drives begin truly cleaning themselves, when files are deleted, file recovery or drive forensics will be more difficult/impossible. I'm sure there will be those who will think this is a bad thing.
_________________________
Glenn
|
Top
|
|
|
|
#324646 - 26/07/2009 20:32
Re: SSDs -- unintended consequences
[Re: gbeer]
|
carpal tunnel
Registered: 17/01/2002
Posts: 3996
Loc: Manchester UK
|
I'm sure there will be those who will think this is a bad thing. Indeed, one of them reads this forum.
_________________________
Cheers,
Andy M
|
Top
|
|
|
|
#324669 - 27/07/2009 14:30
Re: SSDs -- unintended consequences
[Re: gbeer]
|
carpal tunnel
Registered: 20/05/2001
Posts: 2616
Loc: Bruges, Belgium
|
So if drives begin truly cleaning themselves, when files are deleted, file recovery or drive forensics will be more difficult/impossible.
I can see how this might be considered a bad thing. Maybe it will be a user selectable setting.
_________________________
Riocar 80gig S/N : 010101580 red Riocar 80gig (010102106) - backup
|
Top
|
|
|
|
#324671 - 27/07/2009 17:23
Re: SSDs -- unintended consequences
[Re: gbeer]
|
carpal tunnel
Registered: 13/07/2000
Posts: 4180
Loc: Cambridge, England
|
So if drives begin truly cleaning themselves, when files are deleted, file recovery or drive forensics will be more difficult/impossible. I'd imagine they won't actually clean themselves on delete, they'll just put those pages back in the pool available for subsequent writes. So it's more like increasing the (already existing) chance that a subsequent write will overwrite the thing you hoped to recover. Peter
|
Top
|
|
|
|
#324691 - 27/07/2009 21:56
Re: SSDs -- unintended consequences
[Re: peter]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
I'd imagine they won't actually clean themselves on delete, they'll just put those pages back in the pool available for subsequent writes. The drive controller can erase old pages that have been trimmed when it doesn't have anything else to do. Depending on what the drive controller firmware does, those erased pages could be gone pretty quickly.
|
Top
|
|
|
|
#324695 - 28/07/2009 00:20
Re: SSDs -- unintended consequences
[Re: peter]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
'd imagine they won't actually clean themselves on delete, they'll just put those pages back in the pool available for subsequent writes. It's not the firmware, really, but a combination of the O/S sending a DSM/TRIM command, and the firmware then doing what it likes with it. On the pre-production unit I have here some drives, it does might erase the data after a TRIM command, eventually.. but not always immediately. Cheers
Edited by mlord (28/07/2009 00:23)
|
Top
|
|
|
|
#324854 - 03/08/2009 14:35
Re: SSDs -- unintended consequences
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Today I finally got the opportunity to run my wiper.sh (version 1.6) TRIM utility for real on my live 120GB SSD. This is the first time in months that the firmware has known about all of the free blocks on the drive, and it does seem to have speeded things up a bit. I don't run detailed benchmarks, though. Cheers
|
Top
|
|
|
|
#325021 - 11/08/2009 04:27
Re: SSDs -- unintended consequences
[Re: drakino]
|
carpal tunnel
Registered: 24/12/2001
Posts: 5528
|
How does it know what blocks are actually free? The Samsung flash controllers apparently know enough about NTFS to read the block bitmap to erase the unused blocks. This obviously isn't great if you don't use NTFS...
|
Top
|
|
|
|
#325040 - 11/08/2009 20:22
Re: SSDs -- unintended consequences
[Re: tman]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Heh.. and obviously not a great idea for when NTFS adds new features someday..
For general purpose GC, the OCZ firmware does NOT know anything about which blocks are free. Rather, it simply does what the Intel SSDs do: shuffles blocks around to create erase-sized blocks of free space.
All of these drives permanently reserve a few percent of raw capacity for GC/spares, so there is always some free space.
With TRIM, the drives then *do* know about real free space, and in theory can do an even better job of things.
Cheers
|
Top
|
|
|
|
#325041 - 11/08/2009 20:23
Re: SSDs -- unintended consequences
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Note that "industrial grade" SSDs, or "server rated" SSDs, may reserve as much as 50% or more of raw flash capacity for GC and wear leveling.
Cheers
|
Top
|
|
|
|
#326173 - 18/09/2009 10:28
Re: SSDs -- unintended consequences
[Re: mlord]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Today I finally got the opportunity to run my wiper.sh (version 1.6) TRIM utility for real on my live 120GB SSD. Cheers Can I use hdparm/wiper.sh to erase a drive completely? I'd like to do this before restoring a windows image using partimage. Thanks, Pim
|
Top
|
|
|
|
#326175 - 18/09/2009 11:20
Re: SSDs -- unintended consequences
[Re: pim]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Can I use hdparm/wiper.sh to erase a drive completely?
Like this: hdparm --security-set-pass NULL /dev/sdX
hdparm --security-erase NULL /dev/sdX Cheers
|
Top
|
|
|
|
#326177 - 18/09/2009 11:40
Re: SSDs -- unintended consequences
[Re: mlord]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
I'm not sure you understood I want to erase the SSD for performance reasons, not security reasons. I would expect something like hdparm --trim-sector-ranges ALL /dev/sdX The SSD is an Intel X25-M 160GB. Thanks, Pim
|
Top
|
|
|
|
#326178 - 18/09/2009 11:57
Re: SSDs -- unintended consequences
[Re: pim]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
I'm not sure you understood I want to erase the SSD for performance reasons, not security reasons. No, I understood perfectly what you wanted. The recipe I gave above does exactly what you want, on *any* SSD. Cheers
|
Top
|
|
|
|
#326180 - 18/09/2009 12:24
Re: SSDs -- erasing them completely
[Re: mlord]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Very good.
Can I use hdparm 9.12 from Fedora 11 or do I need to compile a more recent version?
Thanks, Pim
|
Top
|
|
|
|
#326184 - 18/09/2009 13:11
Re: SSDs -- erasing them completely
[Re: pim]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Hmmm...
# cat /proc/version
Linux version 2.6.29.5-191.fc11.x86_64
(mockbuild@x86-5.fedora.phx.redhat.com)
(gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) )
#1 SMP Tue Jun 16 23:23:21 EDT 2009
# ./hdparm -V
hdparm v9.27
# lsscsi
[0:0:0:0] cd/dvd SONY DVD-ROM DDU1615 FYS3 /dev/sr0
[2:0:0:0] disk ATA INTEL SSDSA2MH16 045C /dev/sda
[3:0:0:0] disk ATA WDC WD1600BEKT-0 11.0 /dev/sdb
[4:0:0:0] disk ATA Maxtor 6Y120L0 YAR4 /dev/sdc
# ./hdparm --security-set-pass NULL /dev/sda
security_password=""
/dev/sda:
Issuing SECURITY_SET_PASS command, password="", user=master, mode=high
SECURITY_SET_PASS: Input/output error
# ./hdparm --security-erase NULL /dev/sda
security_password=""
/dev/sda:
Issuing SECURITY_ERASE command, password="", user=master
ERASE_PREPARE: Input/output error
Pim
Edited by pim (18/09/2009 14:38) Edit Reason: folded a gawdawful long line
|
Top
|
|
|
|
#326186 - 18/09/2009 13:24
Re: SSDs -- erasing them completely
[Re: pim]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Either the BIOS or the operating system has "frozen" security on the drive. Just power the drive off/on (within 5 seconds), wait another half minute, then do the commands again.
-ml
And trim that gawdawful long line from your posting, so that we don't all have to scroll sideways for the rest of this thread!!
Edited by mlord (18/09/2009 13:26)
|
Top
|
|
|
|
#326195 - 18/09/2009 15:11
Re: SSDs -- erasing them completely
[Re: mlord]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Either the BIOS or the operating system has "frozen" security on the drive. Just power the drive off/on (within 5 seconds), wait another half minute, then do the commands again.
Moved the drive from my "clone" PC to the target laptop. Still the same errors. Maybe this is relevant:
hdparm -I /dev/sdb
[ .... ]
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Pim
|
Top
|
|
|
|
#326208 - 18/09/2009 19:18
Re: SSDs -- erasing them completely
[Re: pim]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
Maybe this is relevant: .. frozen Exactly as I said: the drive has been frozen by the BIOS or operating system. The only way to un-freeze a drive is a power cycle. So just hot unplug it from the laptop, and plug it directly back in again within a few seconds. Linux won't care, and the drive will then be unfrozen. Cheers
|
Top
|
|
|
|
#327119 - 27/10/2009 21:00
Re: SSDs -- erasing them completely
[Re: mlord]
|
carpal tunnel
Registered: 12/11/2001
Posts: 7738
Loc: Toronto, CANADA
|
Any thoughts on this entry level product: Kingston SSDNow V Series 40GB Boot DriveI'd like to use something similar as a boot drive for my PVR server which runs 24/7.
|
Top
|
|
|
|
#327125 - 27/10/2009 22:27
Re: SSDs -- erasing them completely
[Re: hybrid8]
|
carpal tunnel
Registered: 17/12/2000
Posts: 2665
Loc: Manteca, California
|
_________________________
Glenn
|
Top
|
|
|
|
#327126 - 27/10/2009 23:53
Re: SSDs -- erasing them completely
[Re: gbeer]
|
carpal tunnel
Registered: 08/06/1999
Posts: 7868
|
That Kingston looks nice since it's an Intel drive.
I'm holding off for now, hoping for a slightly more affordable high speed SSD in the 256gb range. Probably going to be hard to hold out though, as we have an Intel SSD on order at work for eval.
|
Top
|
|
|
|
#327135 - 28/10/2009 11:08
Re: SSDs -- erasing them completely
[Re: hybrid8]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14493
Loc: Canada
|
It may be "Intel built", but from the specs it is pretty obviously not an Intel SSD. Much slower than the real Intel models. Until we see some independent reviews of it, I'd stay away from this or any SSD. The crappy ones can be really, really bad. EDIT: Mmm.. anandtech reviews are often reliable, and they seem to like it, so.. go crazy if the speed is good enough for the priceGo with a real Intel SSD, or with an OCZ Agility (or Vertex). Those are all very, very fast, and well supported with firmware updates (including TRIM). My PVR here now boots/runs from a barebones 32GB SSD I got as a "factory sample". Just a bare PCB with chips, no case.
Edited by mlord (28/10/2009 11:14)
|
Top
|
|
|
|
#327137 - 28/10/2009 11:12
Re: SSDs -- erasing them completely
[Re: mlord]
|
carpal tunnel
Registered: 12/11/2001
Posts: 7738
Loc: Toronto, CANADA
|
The Anandtech review is pretty decent. It's mainly a review about the Intel SSDs but they've recently expanded it to include the Kingston. Newegg is supposed to debut the product at US$85 after a rebate on November 9th (down from about $115)
|
Top
|
|
|
|
|
|