Slashdot Mirror
Solid State Drives Tested With TRIM Support
Vigile writes "Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues. The promised land is supposed to be the mighty TRIM command — a way for the OS to indicate to the SSD a range of blocks that are no longer needed because of deleted files. Apparently Windows 7 will implement TRIM of some kind but for now you can use a proprietary TRIM tool on a few select SSDs using Indilinx controllers. A new article at PC Perspective evaluates performance on a pair of Indilinx drives as well as the TRIM utility and its efficacy."
I finally got the opportunity to test out SSDs this year. There may be the odd teething problem to get over, but in my mind there is no market in the future for mechanical drives except maybe as cheap low-speed devices for storing non-critical information... in much the same way as tape drives were used a few years ago.
Even the best consumer-level SSDs like the Intel x-25m/e use a volatile RAM cache to speed up the writes. In fact, with the cache disabled, random write IOPS drops to about 1200, which is only about three or four times as good as a 15k 2.5" drive. The more expensive truly-enterprise SSD drives which don't need a volatile write cache cost at LEAST $20/GB, so the $/(safe random write iop) ratio is actually still pretty close, and cheap SATA drives may actually be even on that metric as the fast enterprise SSDs. Granted, this shouldn't be the case in a year, but that's where it is right now. (Also, the performance-per-slot is a lot higher for SSDs, which can translate into different $ and power and space savings.)
Because, basically, flash drives are laid in levels.
When you delete, you simply map logical space as free.
If you go to use that free space later, you find that area, and drop shit into it. It's I dunno, a 32 KB block of memory called a page. If the page is full (to the point where you can't fit your new shit) of "deleted" files, you first need to write over those deleted files, then write your actual data.
If the logical space is full with good, fragmented (with deleted files interspersed) files, you need to read out to memory, reorder the living data and remove the deleted data, add in the full page back.
Think of it as having a notebook.
You can write to 1 page at a time, only.
Page 1 write
Page 2 write
Page 3 write
Page 2 delete
Page 2 write (still space)
Page 2 write (not enough space, write to page 4 instead)
Page 2 delete
Page 2 write (not enough space, no more blank pages, read page 2 and copy non-deleted shit to scratch paper, add new shit to scratch paper, cover page 2 in white out, copy scratch paper to whited-out page 2)
Something as simple as deleting the wrong partition becomes an irreversible operation if you do it using a tool that supports TRIM on TRIM-enabled hardware.
Even if you restore the partition table from a backup, you will likely suffer silent file system corruption, which may even not be apparent until it's too late.
If TRIM support is actually implemented on the device, the device is free to 'lose' data on TRIMmed blocks until they are written at least once.
throw new SuccessException("Sig read successfully");
Very interesting, I assumed the problem was similar to fragmentation and wondered why nobody compared it as such.
Now, your explanation makes things much more clearer, the global problem is amplified by the additional problem you described.
Now would implementing the logic to control the SSD entirely at the OS/FS level be much slower than implementing it in silicon in the SSD itself ?
As you said, I now understand that the OS/FS would now have to be aware of the underlying media ;-)
Everything I write is lies, read between the lines.
Obviously, the firmware needs to be able to detect when data on disk gets obsoleted, and can safely be deleted. The problems with this are that this leads to *very* complicated translation tables - logical disk blocks end up having no relation at all to physical ones, and the SSD needs to track those mappings.
Would it solve the problem (or, I guess I should say, remove the symptoms... for a while, at least) to do a full backup, format the SSD, and restore? I know it's not an ideal solution but rsync or Time Machine would make it pretty painless.
Also, if I had an SSD and was browsing a lot I could see making a ramdisk for things like browser cache files. Too bad Safari and Firefox don't seem to let you specify where you want your cache to be anymore, like old browsers used to. I guess you could make a symlink or something but then you'd HAVE to have that drive mounted.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
How about hibernate to disk? If you have lots of good SSD that should be very fast shouldn't it?
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
if by "proven rock-solid" you mean horrid fidelity and media degradation rates, i'd say you are correct about tapes.
[citation needed]
Tapes probably have a better unrecoverable error rate that drives and don't have bits flip randomly while data is at rest like hard drives are found to do. See the talk entitled "No Terabyte Left Behind" given by Andrew Hume at LISA '07 (Wed. 4-6pm):
http://www.usenix.org/events/lisa07/tech/
hey're wasting a LOT of time just retrieving data.
High speed drives can go from shelf to data in a maximum of 60 seconds.
you should really consider a SAN NAS or similar.
Tapes have the highest measure of density when it comes to TB/kW and TB/sq. of data centre floor space. LTO-4 is up to 800 GB native in a tiny little package that takes no power, and LTO-5 is currently in draft and will be 1.6 TB native (add compression for fun). With LTO-4 (and other tape standards as well) and above there's also a standardized way to encrypt the data (AES-256), so if it goes offsite you don't have to worry about data loss.
Tape may not be for everyone, but there are certain things for which there is no replacement for. CERN is using tape to archive the 15 PB/year of data that's going to be generated by LHC: do you want to know how much power to would take to have 15 PB on SAN / NAS? Then take that power and multiply it by 2 or 3 to running the cooling.