Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Data Storage Hardware

Solid State Drives Tested With TRIM Support 196

Posted by samzenpus from the try-them-out dept.
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."
This discussion has been archived. No new comments can be posted.

Solid State Drives Tested With TRIM Support More

Solid State Drives Tested With TRIM Support

Comments Filter:

  • But its the future (Score:5, Interesting)

    by telchine ( 719345 ) * on Wednesday June 17, 2009 @06:44PM (#28367857)

    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.

    • The mechanicals may be able to stay ahead in capacity for a long long time, even though they obviously have no hope of competitng in the performance arena ever again.

      • Not true I don't think. SSDs already beat HDDs in terms of data density, as can be observed by the fact that you can buy 512GB 2.5" SSDs (for silly money), but only 500GiB HDDs. The only factor that HDDs win on now is price, and I don't expect it to take long before that changes.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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.

      Well damn, I'll just have to tell our customer that has something like a 30 petabyte TAPE archive that's growing by about a terabyte or more each and every day that they're spending money on something you say is, umm, outdated and these newfangled devices that the next power surge will totally fry are the wave of the future.

      Guess what? There's a whole lot more money spent on proven rock-solid technology by large organizations then you apparently know.

      Tape and hard drives are going NOWHERE. For a long, lon

      • Re:But its the future (Score:4, Interesting)

        by MeatBag PussRocket ( 1475317 ) on Wednesday June 17, 2009 @07:54PM (#28368349)

        if by "proven rock-solid" you mean horrid fidelity and media degradation rates, i'd say you are correct about tapes. if you're client has a 30 petabyte tape archive there is probably some horrible inefficiency goin on. (i'm sure you probably have little control ofer the situation, i have similar clients) but if they have 30Pb of data on tape that they access regularly, they're wasting a LOT of time just retrieving data. you should really consider a SAN NAS or similar. HDD storage is very cheap these days and LTO4 tapes are pretty pricey. we all know they have shoddy storage quality to boot. if they dont access it regulary then its probably a real waste of money to own, record and store 30Pb of data. either way, just the physical storage of that many tapes is probably about equivelant to the sq. footage needed for a rack or 2 (or 3) of blade servers with the same storage capacity.

  • What I really want to know (Score:3, Insightful)

    by earthforce_1 ( 454968 ) <earthforce_1@yaho[ ]om ['o.c' in gap]> on Wednesday June 17, 2009 @06:48PM (#28367891) Journal

    Which Linux filesystem works best with SSDs? I don't intend to touch Win7.

    • I bought a WinTec FileMate Ultra 24G from Tiger Direct that plugs into the ExpressCard Slot. I am now using that as the boot partition with reiserfs (v3), elevator=noop, and mounted noatime. This might not give the very best performance but it is much faster than the stock HD. OpenOffice loads in 2 seconds. I turned down the /sys/block/sdb/queue/read_ahead_kb but I'm not sure where it should be. I put my logs on tmpfs. Some people put the Firefox cache on tmpfs.

    • Re: (Score:2)

      by zdzichu ( 100333 )

      In Linux TRIM commands are issued by ext4 and btrfs. Btrfs also have two SSD modes for allocator, but is not meant for production now. There are probably other linux filesystem issuing TRIM, as it's implemented few kernel releases ago.

  • can someone explain why fragmentation in the mapping between logical blocks and
    physical addresses causes performance degradation?

    is it an issue with logically sequential reads being spread across multiple pages?

    a multi-level lookup to perform the mapping?

    ?

    • Re:fragmentation? (Score:5, Informative)

      by Vigile ( 99919 ) * on Wednesday June 17, 2009 @07:06PM (#28368019)

      This older Slashdot post linked in the story links to a story that covers that topic very well: http://www.pcper.com/article.php?aid=669 [pcper.com]

      • Re: (Score:3, Insightful)

        by fimbulvetr ( 598306 )

        It's extremely unfair to link to the print version of that article. Anand put an immense amount of time into that (and everything before it!) and scarred quite a few bridges to bring it to light for his readers - there are very, very few reviewers out there that would do that for their readerbase. The least you could do is offer him and his site _some_ respect.

    • Re:fragmentation? (Score:4, Interesting)

      by sexconker ( 1179573 ) on Wednesday June 17, 2009 @07:27PM (#28368197)

      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)

    • Re:fragmentation? (Score:5, Informative)

      by cbhacking ( 979169 ) <been_out_cruising-slashdot&yahoo,com> on Wednesday June 17, 2009 @07:27PM (#28368199) Homepage Journal

      Disclaimer: I am not a SSD firmware author, although I've spoken to a few.*

      As best I can understand it, the problem is that writes are scattered across the physical media by wear-leveling firmware on the disk. In order to do this, the firmware must have a "free list" of sorts that allows it to find an un-worn area for the next write. Of course, this unworn area also needs to not currently be storing any relevant data.

      Now, consider a SSD in use. Initially, the whole disk is free, and writes can go anywhere at all. They do, too - you end up with meaningful (at some point) data covering the entirety of the physical memory cells pretty quickly (consider things like logfiles, pagefiles, hibernation data, temporary data, and so forth). Obviously, most of that data doesn't mean anything anymore - to the filesystem, only perhaps 20% of the SSD is actually used, after 6 months. However, the SSD's firmware things that every single part has now been used.

      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. The other problem is that these tables get *huge* - a typical home system might have between 100K and 1M files on it after a few months of usage, but probably generates and deletes many thousands per day (consider web site cookies, for example - each time they get updated, the wear leveling will write that data to a new portion of the physical storage).

      Maintaining the tables themselves is possible, and when a logical block gets overwritten to a new physical location, the old location can be freed. The problem is that this freeing comes at the same time that the SSD needs to find a new location to write to, and the only knowledge it has about physical blocks which can safely be overwritten is ones where the logical block has been overwritten already (to a different physical location). Obviously, the lookup into the table of active blocks has to be indexed by logical block, which may make it difficult to locate the oldest "free" physical blocks. This could lead to searches that, even with near-instant IO, result in noticeable slowdowns.

      Enter the TRIM command, whereby an OS can tell the SSD that a given range of logical blocks (which haven't been overwritten yet) are now able to be recycled. This command allows the SSD to identify physical blocks which can safely be overwritten, and place them in its physical write queue, before the next write command comes down from the disk controller. It's unlikely to be a magic bullet, but should improve things substantially.

      * As stated above, I don't personally write this stuff, so I may be mis-remembering or mis-interpreting. If anybody can explain it better, please do.

      • Re:fragmentation? (Score:5, Informative)

        by aztektum ( 170569 ) on Wednesday June 17, 2009 @08:02PM (#28368399)

        For a thorough (RE: long) primer on SSDs and long term performance woes, Anand's overview [anandtech.com] is a must read.

      • Re: (Score:3, Interesting)

        by sootman ( 158191 )

        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

        • It might ease the problem, but it wouldn't solve it. The controller on the drive needs to clear the pages and re-set everything back to zero, it doesn't do that with just a format as far as I am aware. You'd need a format -and- a trim to get it back to like-new speeds.

          I like your idea for ramdisks and cache though.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          browser.cache.disk.parent_directory

        • Re: (Score:2)

          by rdebath ( 884132 )

          Yes this would work very well.

          BUT. you MUST tell the drive you've done this, with the previous drives the only way is to use the drive's secure erase command to wipe the drive.

          With these new drives you could just TRIM all the free space occasionally.

      • Re: (Score:3, Informative)

        by 42forty-two42 ( 532340 )
        The problem isn't scanning metadata - the problem is relocating data prior to an erase. Flash memory is built into erase blocks that are quite large - 64k to 128k is typical. You can write to smaller regions, but to reset them for another write you have to pave over the neighborhood. However the OS is sending writes at the 512-byte sector granularity. So the drive has to essentially mark the old location for the data as obsolete, and place it somewhere else.

        When the drive has been used enough, however, it m

    • Re: (Score:3, Insightful)

      by Bigjeff5 ( 1143585 )

      In very simple terms (because I'm no expert), it's because of the way SSDs deal with wear leveling and the fact that a single write is non-sequential. When it writes data, it is writing to multiple segments across multiple chips. It is very fast to do it this way, in fact the linear alternative creates heavy wear and is significantly slower (think single chip usb flash drives) than even spinning disk tech, and so this non-sequential write is essential.

      Now, to achieve this, each chip is broken down into se

      • When you delete data, you are deleting little bits spread all over the physical drive.

        The biggest problem is that a delete in most filesystems simply marks the space in the index on the device as free. However most filesystems leave the deleted data in place without writing anything over the top until that space is re-allocated. Hard disks don't typically need to know which sectors of the physical storage are actually in use. If you tell an SSD that this block is no longer required it can start erasing the physical chips and add them to the internal free list ready for the next data to be wr

        • Re:fragmentation? (Score:4, Interesting)

          by ls671 ( 1122017 ) * on Wednesday June 17, 2009 @08:29PM (#28368551) Homepage

          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 ;-)

          • Re: (Score:2)

            by lagfest ( 959022 )

            probably not. but neither OS vendors nor SSD manufacturers would want that.

            There's no backwards compatibility, SSD vendors have to write drivers for every OS, and so on.

            • Re: (Score:2)

              by ls671 ( 1122017 ) *

              Well, my understanding is too fresh to judge the case but based on experience; standard interfaces usually emerge after a period of, say, 10 to 20 years after the raw technology with proprietary drivers emerges.

              Please correct me if I am wrong but wasn't this the case for hard drives ?

              Of course, the technology has to last that long for standards to emerge. ;-))

      • Re:fragmentation? (Score:5, Informative)

        by 7 digits ( 986730 ) on Wednesday June 17, 2009 @10:51PM (#28369397)

        Once upon a time, a technical subject on /. gave insightful and informative responses that were modded up. Time changes, I guess.

        The "fragmentation" that SSD drive have don't really come from wear leveling, or from having to find some place to write things, but from the following properties:

        * Filesystems read and write 4KiB pages.
        * SSD can read many time 4KiB pages FAST, can write ONCE 4KiB pages FAST, but can only erase a whole 512KiB blocks SLOWLY.

        When the drive is mostly empty, the SSD have no trouble finding blanks area to store the 4KiB write from the OS (he can even cheat with wear leveling to re-locate 4K pages to blank spaces when the OS re-write the same block). After some usage, ALL THE DRIVE HAVE BEEN WRITTEN TO ONCE. From the point of view of the SSD all the disk is full. From the point of view of the filesystem, there is unallocated space (for instance, space occupied for files that have been deleted).

        At this point, when the OS send a write command to a specific page, the SSD is forced to to the following:

        * read the 512KiB block that contain the page
        * erase the block (SLOW)
        * modify the page
        * write back the 512KiB block

        Of course, various kludges/caches are used to limit the issue, but the end result is here: writes are getting slow, and small writes are getting very slow.

        The TRIM command is a command that tell the SSD drive that some 4KiB page can be safely erased (because it contains data from a delete file, for instance), and the SSD stores a map of the TRIM status of each page.

        Then the SSD can do one of the following two things:

        * If all the pages of a block are TRIMed, it can asynchronously erase the block. So, the next 4KiB write can be relocated to that block with free space, and also the 127 next 4KiB writes.
        * If a write request come and there is no space to write data to, the drive can READ/ERASE/MODIFY/WRITE the block with most TRIMed space, which will speed up the next few writes.
        (of course, you can have more complex algorithms to pre-erase at the cost of additional wear)

    • Coriolis Systems (who produces iDefrag) jokingly referred to that issue on their blog.

      " Ironically even SSDs, where you would expect the uniform access time to render fragmentation a problem of the past, still have various problems caused by exactly the same issue(1)'

      of course, they add:

      1 For avoidance of doubt, we strongly recommend that you don't try to defragment your SSD-based volumes. The fragmentation issue on SSDs is internal to their implementation, and defragmenting the filesystem would only make m

    • Re: (Score:2)

      by sjames ( 1099 )

      In a nutshell, the page size of the flash is larger than the logical sector size, but flash can only erase whole pages at a time (and erase isn't a fast operation). So when blocks get re-written, the old content doesn't go away by default. Instead, the logical to physical mapping is changed to point to an already blank area and the old content is marked for reclaimation.

      When the last logical block in a page is invalidated, then the page can be scheduled to be erased and returned to the available list.

      The ca

  • Potential data recovery problems (Score:3, Interesting)

    by quazee ( 816569 ) on Wednesday June 17, 2009 @07:48PM (#28368319)
    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.

    • Re: (Score:2)

      by Spit ( 23158 )

      I would never, ever trust a filesystem after an event like this. Ever. Do your backups.

    • Re:Potential data recovery problems (Score:4, Insightful)

      by steveha ( 103154 ) on Wednesday June 17, 2009 @09:56PM (#28369095) Homepage

      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.

      This seems needlessly verbose. Let me shorten it for you:

      Deleting a partition should always be considered an irreversible operation.

      Hmmm, even shorter:

      Don't delete a partition unless you want it to go away forever.

      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.

      If I understand you correctly, you are suggesting that a disk partitioning tool will use TRIM to not only wipe the partition table itself, but also nuke the partition data from orbit. And you the point out that it would not be adequate to rewrite just the sectors of the partition table.

      If so, then the answer is: you don't just restore the partition table, you restore the whole partition (including data) from backup.

      I for one consider much-faster write speeds to be a bigger advantage than possibly being able to reverse a partition deletion.

      steveha

    • Re: (Score:2)

      by rdebath ( 884132 )

      There will NOT be silent file corruption. If the OS TRIMs the entire partition it will appear to have been wiped by the drive. The physical blocks will be moved back onto the drive's free list the logical blocks will be mapped to the 'null block'.

      End result TRIM looks like a fast wipe and the data will be completely erased at the ATA level but the data won't be erased at the flash level until later.

  • Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues.

    Who cares how they perform. All they have to do is sit there and scare away enemy fleets.

  • I'd love to get me some trim! [urbandictionary.com]

  • The most important point of hard disks are being amazingly multi platform. I didn't like the sound of "Windows driver", "OS support" to perform nicely.

    SSD guys really better stick to the standards and never, ever do anything requiring a "driver" on host OS. For example, there are G4 Mac owners who happily upgrades their "old tech" magnetic drives to 500 GB or even 1TB. Who will write driver for them? Apple? SSD vendor? I don't think so.

    In fact, HD vendors really better stay away from writing anything except

  • Will it work on my Commodore? [ntrautanen.fi]

  • Where are all the wonderful SSD/HD hybrid drives that were supposed to come out and prevent many of the problems SSDs have?

    My dad bought me an SSD for my birthday, and it was one of those models that has horrible studdering issues (which, from what I'm reading, covers most SSDs). That was a lot of money for a drive that let me install drivers about 20 times slower than a hard drive would, and caused my machine to freeze for 20-40 seconds at a time while just surfing the web. That was after disabling all t

    • Never mind about the mixing of flash types. I did my research.

      I still want to know where the hybrids are.

Slashdot Top Deals

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)

Close