Missing TRIM - Does it Matter?

Clearly the performance of two X25-Vs in RAID 0 is great, but you do lose TRIM - isn't that a dealbreaker? Honestly, it depends. For sequential accesses, TRIM isn't necessary on the Intel drives. The X25 controller does a good job of aggressively cleaning and recycling NAND blocks and you'll pretty consistently write at peak performance if your workload is almost all sequential.

The more random your access pattern is, the more you'll miss TRIM. Thankfully desktops don't spend too much of their time randomly writing data across the drive, but I'd say a good 30% of most desktop writes are random to an extent. Over time, these random writes will build up and bring down the overall performance of your RAID array until you either secure erase the drives or write sequentially to all available free space.

There is one other option for curbing the performance degradation before it happens. Remember the relationship between spare area and write amplification:

The more random your workload, the higher your write amplification (and thus the lower your performance, shorter your NAND lifespan). Increasing spare area can go a long way to reducing write amplification. While it can't eliminate it, it can definitely make a dent.

If you're looking to keep performance as high as possible with a pair of X25-Vs in RAID, you can always allocate more NAND as spare area. Secure erase each drive, create your RAID array, and then create your partition on the drive smaller than max capacity (try 10 - 20% smaller). The unpartitioned space should automatically be used by the controller as spare area. To test the effectiveness of this approach I took an X25-V, filled it with garbage data, and then wrote random data across the drive as fast as possible for 20 minutes. I then ran HD Tach to get a visualization of write latency (expressed by sudden drops in bandwidth) vs. LBA:

A standard 80GB X25-M wouldn't be this bad off, the X25-V gets extra penalized by having such a limited capacity to begin with. You can see that the drive is attempting to write at full speed but gets brought down to nearly 0MB/s as it has to constantly clean dirty blocks. Constant TRIMing would never let the drive get into this state. It's worth mentioning that a desktop usage pattern shouldn't get this happen either. Another set of sequential writes will clean up most of this though:

Intel's controller is very resillient. Even without TRIM, as long as your access pattern has some amount of a sequential component you'll be able to eventually recover performance.

Now look at what happens if we only use 60GB of the 74.5GB RAID 0 array upon creation and run the same test:

Performance isn't nearly as bad. That added spare area really comes in handy. Of course another pass corrects nearly everything:

If you don't need the added space, using a smaller partition is a great way to ensure high performance for as long as possible. The effectiveness of this approach is a difficult thing to benchmark given that it's only after months of normal use that you get enough random writes to the drive to be a problem. The good news is that even if you bombard the X25-Vs with random writes, the drives can quickly recover as soon as they're hit with some sequential data.

AnandTech Storage Bench Final Words
Comments Locked

87 Comments

View All Comments

  • Makaveli - Tuesday, March 30, 2010 - link

    Why are so many of you having difficultly understanding this. YOU DO NOT GET TRIM SUPPORT WITH THE NEW INTEL DRIVERS IF YOU HAVE A RAID ARRAY BUILT OF JUST SSDs!

    Where every you guys are reading that stop its wrong!

  • vol7ron - Tuesday, March 30, 2010 - link

    Finally a RAID! Thank you, thank you, thank you. Just a few days too late before I bought the 80GB, but still this makes your review a little more meaningful - it is essentially the equivalent of showing overclocks for CPUs and more meaningful, since HDs are a bottleneck.

    Advice:
    RAID-0s see a greater impact with 3 or more HDs. I think the impact is exponential to the number of drives in the array, not just seemingly double. I know TRIM is not supported, but if you could get one more 40GB drive and also include the impact, that would be nice - I would consider anything more than 3 drives in the array as purely academic; 3 or less drives is a practical (and realistic) system setup.


    Notes to others:
    I saw the $75 discount on Newegg for 80GB X25MG2 (@ $225) and decided to grab it, since one of my 74GB Raptors finally failed in RAID. This discount (or price drop) is most likely due to the $125 40GB version. I also picked up Win7 Ultimate x64, to give it a try.
  • cliffa3 - Tuesday, March 30, 2010 - link

    Anand,

    On an install of Win7, I'm guessing a good bit of random writes occur.

    How much longer would you stave off the performance penalty due to having no TRIM with RAID if you took an image of the drive after installation, secure erased, and restored the image?

    Please correct me if I'm wrong in assuming restoring an image would be entirely sequential.

    I would probably image it anyway, but just trying to get a guess on what you think the impact would be in the above scenario to see if I should immediately secure erase and restore.

    I also would be interested in how much improvement you get by adding another drive to the array in RAID 0...is it linear?
  • GullLars - Tuesday, March 30, 2010 - link

    Some of the powerusers i know have used the method of secure erase + image to restore performance if/when it degrades. Mostly they do it after heavy benchmarking or once every few months on their workstations (WMvare, databases and the like).

    RAID scales linearly as long as the controller can keep up. This is the RAW performance numbers, the real life impact is not linear, and will have diminishing returns due to storage performance being divided in two major categories: Throughput and accesstime. Throughput scales linearly, accesstime stays unchanged. Though average accesstime for larger blocks and under heavy load takes less of a hit in RAIDs.

    Intels southbridges scale to roughly 600-650MB/s, and i've seen 400+ MB/s done at 4KB random.

    As for random read scaling in RAID, you have the formula IOPS = {average accesstime} * {Queue Depth}
    Average accesstime has a more gentle slope in RAID as the Queue Depth scales the more units you put in the RAID, but at low QD (1-4) there is little to gain for blocks smaller than stripe size. No matter how may SSDs you add in the RAID, you will never get scaling more than QD * IOPS @ QD 1.
  • ThePooBurner - Tuesday, March 30, 2010 - link

    Check out this video of 24 SSDs in a raid 0 array. Mind blowing.

    http://www.youtube.com/watch?v=96dWOEa4Djs
  • GullLars - Tuesday, March 30, 2010 - link

    Actually, that RAID has BAD performance compared to the number of SSDs.
    You are blinded by the sequential read numbers. Those Samsung SSDs have horrible IOPS performance, and the cost of the setup in the video compared to performance is just outright awfull.

    You can get the same read bandwidth with 12 x25-V's, and at the same time 10X the IOPS performance.
    Or if you choose to go for C300, 8 C300 will beat that setup in every test and performance meteric you can think of.

    Here is a youtube video of the performance of a Kingston V 40GB launching 50 apps for you to compare to the Samsung setup:
    http://www.youtube.com/watch?v=sax5wk300u4&fea...

    I will also point out my 2 Mtron 7025 SSD that were produced in dec 2007 can open the entire MS office 2007 suite in 1 second, from SB650 and prefetch/superfetch deactivated.
  • Slash3 - Tuesday, March 30, 2010 - link

    Speaking of which, is there a "report abuse" button for comments on this new site design system? I didn't notice one, just in fumbling around a bit.
  • waynethepain - Tuesday, March 30, 2010 - link

    Would defragging the SSDs mitigate some of the build up of garbage?
  • 7Enigma - Tuesday, March 30, 2010 - link

    You do not defrag an SSD.
  • GullLars - Tuesday, March 30, 2010 - link

    You don't need to defrag a SSD, but you can. This does not affect the physical placement of the files, but will defragment their LBA fragmentation in the file tables. Since most SSDs can reach full bandwidth (or close to) at 32-64KB random read, you need a seriously fragmented system before you will notice anything. There are almost no files that will get fragmented into that small pieces, and even if you get 50 files each in 1000 fragments of 4KB, the SSD will read each one when they are needed in a fraction of a second.

    It doesn't hurt to defrag if you notice a few files in hundreds or thousands of fragments, the lifespan of the SSD will be unaffected by one defrag a week, but it will cause spikes of random writes, wich may cause a _temporary_ performance degrading if you don't have TRIM.

Log in

Don't have an account? Sign up now