Original Link: http://www.anandtech.com/show/6161/intel-brings-trim-to-raid0-ssd-arrays-on-7series-motherboards-we-test-it
Intel Brings TRIM to RAID-0 SSD Arrays on 7-Series Motherboards, We Test Itby Anand Lal Shimpi on August 16, 2012 12:04 AM EST
In an unusually terse statement, Intel officially confirmed that the ATA TRIM command now passes through to RAID-0 SSD arrays on some systems running Intel's RST (Rapid Storage Technology ) RAID driver version 11.0 and newer. The feature is limited to Intel 7 series chipsets with RST RAID support and currently only works on Windows 7 OSes, although Windows 8 support is forthcoming.
As soon as I got confirmation from Intel, I fired up a testbed to confirm the claim. Before I get to the results, let's have a quick recap of what all of this means.
Why does TRIM Matter?
The building block of today's SSDs that we love so much is 2-bit-per-cell MLC NAND Flash. The reason that not all SSDs are created equal is because of two important factors:
1) Each NAND cell has a finite lifespan (determined by the number of program and erase cycles), and
2) Although you can write to individual NAND pages, you can only erase large groups of pages (called blocks)
These two factors go hand in hand. If you only use 10% of your drive's capacity, neither factor is much of an issue. But if you're like most users and run your drive near capacity, difficulties can arise.
Your SSD controller has no knowledge of what pages contain valid vs. invalid (aka deleted) data. As a result, until your SSD is told to overwrite a particular address, it has to keep all data on the drive. This means that your SSD is eternally running out of free space. Thankfully all SSDs have some percentage of spare area set aside to ensure they never actually run out of free space before the end user occupies all available blocks, but how aggressively they use this spare area determines a lot.
Aggressive block recycling keeps performance high, at the expense of NAND endurance. Conservative block recycling preserves NAND lifespan, at the expense of performance. It's a delicate balance that a good SSD controller must achieve, and there are many tricks that can be employed to make things easier (e.g. idle time garbage collection). One way to make things easier on the controller is the use of the ATA TRIM command.
In a supported OS, with supported storage drivers and on an SSD with firmware support, the ATA TRIM command is passed from the host to the SSD whenever specific logical block addresses (LBAs) are no longer needed. In the case of Windows 7, a TRIM command is sent whenever a drive is formatted (all LBAs are TRIMed), whenever the recycle bin is emptied or whenever a file is shift + deleted (the LBAs occupied by that file are TRIMed).
The SSD doesn't have to take immediate action upon receiving the TRIM command for specific LBAs, but many do. By knowing what pages and blocks no longer contain valid data, the SSD controller can stop worrying about preserving that data and instead mark those blocks for garbage collection or recycling. This increases the effective free space from the controller's perspective, and caps a drive's performance degradation to the amount of space that's actively used vs. a continuing downward spiral until the worst case steady state is reached.
TRIM was pretty simple to implement on a single drive. These days all modern SSDs support it. It's only if you have one of the early Intel X25-M G1s that you're stuck without TRIM. Drives that preceded Intel's X25-M are also TRIMless. Nearly all subsequent drives we recommended either had TRIM support enabled through a firmware update or had it from the start.
Enabling TRIM on a RAID array required more effort, but only on the part of the storage driver. The SSD's firmware and OS remain unchanged. Intel eventually added TRIM support in its RAID drivers for RAID-1 (mirrored) arrays, but RAID-0 arrays were a different story entirely. There's a danger in getting rid of data in a RAID-0 array, if a page or a block gets TRIMed on one drive that's actually necessary, the entire array can be shot. There was talk of Intel enabling TRIM support on RAID-0 arrays as early as 2009, but given the cost of SSDs back then not many users were buying multiple to throw in an array.
The cost of SSDs has dropped considerably in the past 4 years. The SSD market is far more mature than it used to be. Intel isn't as burdened with the responsibility of bringing a brand new controller and storage technology to market. With some spare time on its hands, Intel finally delivered a build of its RAID drivers that will pass the ATA TRIM command to RAID-0 arrays.
The requirements for RAID-0 TRIM support are as follows:
A 7-series motherboard (6-series chipsets are unfortunately not supported).
Intel's Rapid Storage Technology (RST) for RAID driver version 11.0 or greater (11.2 is the current release)
Windows 7 (Windows 8 support is forthcoming)
The lack of support for 6-series chipsets sounds a lot like a forced feature upgrade. Internally Intel likely justifies it by not wanting to validate on older hardware, but I don't see a reason why TRIM on RAID-0 wouldn't work on 6-series chipsets.
I am not sure if TRIM will work on RAID-10 arrays. I'm going to run some tests shortly to try and confirm. Update: I don't believe it works on RAID-10 arrays. I'm still running tests to confirm but so far it looks like the answer is no.
Testing TRIM on RAID-0
I set up a Z77 testbed using Intel's DZ77GA-70K motherboard. I configured the board for RAID operation and installed Windows 7 SP1 to a single boot SSD. I then took two Samsung SSD 830s and created a 128GB RAID-0 array (64GB + 64GB). I picked the 830 because it benefits tremendously from TRIM, when full and tortured with random writes the 830's performance tanks. I secure erased both drives before creating the RAID array to ensure I started with a clean slate.
The 64GB Samsung SSD 830 is good for almost 500MB/s in sequential reads and under 160MB/s sequential writes. Two of them in RAID-0 should be able to deliver over 1GB/s of sequential read performance and over 300MB/s in sequential writes. A quick pass of HDTach confirms just that:
Take a moment to marvel at just how much performance you can get out of two $90 SSDs.
For the control run I used Intel's 10.6 RST drivers (10.6.0.1022). I filled the array with sequential data, then randomly wrote 4KB files over the entire array at a queue depth of 32 for 30 minutes straight. I formatted the array (thus TRIMing all LBAs) and ran an HD Tach pass to see if performance recovered. Remember if the controller was told that all of its data was invalid, a sequential write pass would run at full speed since all data would be thrown away as it was being overwritten. Otherwise, the controller would try to preserve its drive full of garbage data as long as possible.
The 10.6 RST drivers don't pass TRIM through to RAID-0 arrays, and the results show us just that:
That's no surprise, but what happens if we do the same test using Intel's 11.2 RST drivers?
Here's what the pass looks like after the same fill, torture, TRIM, HD Tach routine with the 11.2 drivers installed:
Perfect. TRIM works as promised. Users running SSDs in RAID-0 on 7-series motherboards can enjoy the same performance maintaining features that single-drive users have.
Bringing TRIM support to RAID-0 arrays provides users with a way of enjoying next-gen SSD performance sooner rather than later, without giving up an important feature. Pretty much all high-end SSDs are capped to 6Gbps limits when it comes to sequential IO. Modern SATA controllers deliver 6Gbps per port, allowing you to break through the 6Gbps limit by aggregating drives in RAID.
The only negative here is that Intel is only offering support on 7-series chipsets and not on previous hardware. That's great news for anyone who just moved to Ivy Bridge and has a RAID-0 array of SSDs, but not so great for everyone else. A lot of folks supported Intel over the past couple of years and Intel has had some amazing quarters as a result - I feel like the support should be rewarded. While I understand Intel's desire to limit its validation costs, I don't have to be happy about it.
For more information on how SSDs work, check out our last major article on the topic.