The skinny on TRIM

[thepriceisright]

Hello all, I've been a long time lurker (obviously) and am fed up with the knowledge level of the forum I usually post on so it's time to move on to greener pastures.

Oh the convoluted TRIM question! I've come across every answer under the sun while searching, hopefully you guys can put them to rest for me and help other people out as well.

1. Is TRIM supported on any RAID controller in existence outside of RAID 0?

2. Are there any controllers that support pass through disks with TRIM outside of the on-board offerings?

3. Does TRIM work on dynamic disks set up in a Windows software RAID?

4. How does one really know if TRIM is working, can it only be tested by doing a benchmark with a fresh drive and then comparing it months later?

There is a lot of info out there but it's all so contradictory, take for example the question about whether or not TRIM is supported in RAID arrays outside of RAID 0 on the Intel platform and you have a reference like this in an anandtech article: "Intel eventually added TRIM support in its RAID drivers for RAID-1 (mirrored) arrays, but RAID-0 arrays were a different story entirely." - http://www.anandtech.com/show/6161/...ssd-arrays-on-7series-motherboards-we-test-it Yet everyone else says RAID-1 does NOT have TRIM support.

Thanks!

 

[Ben90]

Well for starters, to test if trim is working:

Open Command Prompt with Administrative privileges (Run as administrator) and enter the follow command.
fsutil behavior query DisableDeleteNotify
If the result is '0' TRIM is enabled.

TRIM should work in theory with any RAID configuration that does not require physical striping of the data e.g. any software RAID and phyiscal RAID 1. I'm sure someone else on here can verify as I only have 1 SSD.

 

[Cerb]

1. AFAIK, Intel supports it for RAID 0 only, and nobody else is really rushing to add support. It is a dangerous proposition for RAID, since TRIM was not defined and implemented with synchronized disks in mind (no hard time limit).

2. AFAIK, no. LSI was supposedly going to add it, but I'm not sure about a time frame.

3. Good question. No Earthly idea.

4. Supposedly:

fsutil behavior query DisableDeleteNotify

But, I get a 0 result with my HDDs. It can tell you that TRIM won't work, if returns non-zero, but you may need another method to check to see that blocks have gotten TRIM applied, which might mean vendor-specific tools.

Ultimately, the best thing to do is to get SSDs that don't rely on TRIM for acceptable steady state performance. Most Marvell-based drives, Samsungs, and Intel-controller-based Intel drives, would fit the bill (Phison and LAM, we'll just have to wait and see about).

 

[hhhd1]

3. I do think so, yes, however I can not verify that info, someone else has to confirm it.

 

[Coup27]

4. How does one really know if TRIM is working, can it only be tested by doing a benchmark with a fresh drive and then comparing it months later?

That's one way but it's quite an inefficient method.

A more technical way is to use a hex editor. Download a hex editor (I think I used winhex) and open a hex view of your disk. Then find a file and write down its location on the disk (offset). Next to the offset will be a set of hexadecimal values which make up the file stored at that location.

Close winhex and delete the file and then empty the recycle bin. Emptying the recycle bin will trigger the trim command. Now leave your PC idle for about 10 minutes. This will give the drives garbage collection time to clean the block where the file was previously stored.

Reopen winhex and take a new snapshot. Search for the offset you noted earlier and next to it should now be a load of zero's. If it is, then you know TRIM is working as that block is now empty (zero = empty).

This procedure works on my single drive but when I ran two drives in RAID0 the location next to the offset would never zero out. This is what I expected as back then TRIM in RAID0 was not supported.

 

[thepriceisright]

Wow, 4 responses already. I should have moved over to these forums years ago.. Gentlemen, your efforts to answer my questions are greatly appreciated!

Well for starters, to test if trim is working:

Thanks Ben! Unfortunately this will only tell you if the OS is sending the TRIM command on to the drive. It doesn't tell you if the command is being ignored.

Ultimately, the best thing to do is to get SSDs that don't rely on TRIM for acceptable steady state performance. Most Marvell-based drives, Samsungs, and Intel-controller-based Intel drives, would fit the bill (Phison and LAM, we'll just have to wait and see about).

Thanks Cerb! I thought about adding this question to my list (does trim really matter for some drives?) but I already knew the answer I was going to get. Everyone says the same thing, GC is "good enough". I've seen a couple of scenarios though where the array's performance was degraded over time and could only be returned by doing a wipe of the drives and starting over. Granted, it could be a number of causes, like not allowing GC to work it's magic, but I'm trying to see if where TRIM can and can't be used.

A more technical way is to use a hex editor. Download a hex editor (I think I used winhex) and open a hex view of your disk. Then find a file and write down its location on the disk (offset). Next to the offset will be a set of hexadecimal values which make up the file stored at that location.

Brilliant! I honestly have never seen this mentioned before, thank you so much for the info.

 

[imagoon]

Most Enterprise SSD's have minimal or no need for TRIM because they maintain spare areas and do copy on writes for performance and wear leveling. No matter how full the Enterprise SSD is, it will always have some % of spare area. 200GB or 256GB of NAND etc. That entire 56GB of spare area is garbage collected as needed because drive knows that it is not in use.

This is the main reason you don't see TRIM in RAID. Add in that there is no real way for the OS to realistically map to the virtual LBA.

It is the drives that have minimal or no spare area that really need TRIM to keep performance up and even then it depends on how good the garbage collection is since most now use copy on writes so they know which block is erasable. TRIM really only helps for deletes.

 

[tweakboy]

Without TRIM and a RAID setup, your SSDs are going to get slower and slower as time goes on.. that is fact! If you check in CrystalDiskInfo the 100 percent will become 97 percent.

What that means is SSD has slowed down big time also the wear and lifetime will decrease without TRIM.

Just like you TRIM your gotee you TRIM your ssd.

 

[imagoon]

Without TRIM and a RAID setup, your SSDs are going to get slower and slower as time goes on.. that is fact! If you check in CrystalDiskInfo the 100 percent will become 97 percent.

What that means is SSD has slowed down big time also the wear and lifetime will decrease without TRIM.

Just like you TRIM your gotee you TRIM your ssd.

Nope. Depends on the SSD. Wear and lifetime has zero to do with TRIM also.

 

[Engineer]

To the OP: Ultimate lurker - joined in December 2003 and have 2 posts - with BOTH OF THEM IN THIS THREAD!!! WOW!!!

1. AFAIK, Intel supports it for RAID 1 only, and nobody else is really rushing to add support. It is a dangerous proposition for RAID, since TRIM was not defined and implemented with synchronized disks in mind (no hard time limit).

Are you saying that Intel supports RAID 1 only or RAID 1 and RAID 0 with TRIM?

I know that with the Z77 chipsets, RAID 0 is supported. I'm not even sure that RAID 1 is supported (yet?)?

 

[tweakboy]

Nope. Depends on the SSD. Wear and lifetime has zero to do with TRIM also.

Yup. Any SSD Samsung Crucial ....... there is a reason for TRIM and Im right on this one brother... :hmm:

It will slow down over time...... with no TRIM , end of story! adios

 

[imagoon]

Yup. Any SSD Samsung Crucial ....... there is a reason for TRIM and Im right on this one brother... :hmm:

It will slow down over time...... with no TRIM , end of story! adios

Still nope. You're stating absolutes and I can think of at least 8 drives off the top of my head where this isn't true at all.

 

[Mark R]

TRIM cannot sensibly be used on RAID with redundancy, because it defeats the parity calculation. The RAID driver would need to keep track of TRIMmed sectors and require additional storage to keep track of this, breaking backwards compatibility and making a simple system very complex.

It is potentially possible to use RAID 1 on drives that guarantee to zero-out a TRIMmed LBA immediately (not all drives do this [some don't zero the sectors, some have a delay, some might ignore TRIM under certain circumstances...], and there isn't a reliable way for the OS to test a drive to see if this is the case - however, there is a new specification in the pipeline which will allow the OS to test for this guaranteed "deterministic TRIM"). Because not all drives guarantee deterministic behavior following TRIM, RAID 1 support for TRIM cannot be guaranteed to work correctly (and as you are using RAID 1 to protect data, using a flaky algorithm is a bad idea). Unsurprisingly, there is pretty much no support for this.

The algorithm for using TRIM in RAID 0 is utterly trivial, so I remain constantly surprised that this isn't universally supported, and that even where it is supported, it took so long.

 

[imagoon]

Mark R, sums it up pretty well. This is why slack space SSD drives should be used in RAID. Picking a random drive such as the Intel 710, you have 200GB of space out of 256GB of NAND. Every write to the drive is copy on write to a sector on the spare area. This balances wear and lets the drive "TRIM" the disk on its own. The drive knows that the source block that was copy on write to a new spare block is eraseable as it has become a spare block. Deleting will not result in a TRIM request in RAID(anything) and it won't matter since the drive has 56GB of spare area any write to that deleted block at some point will become a "copy on write" freeing it up anyway. This applies to the non enterprise Intel drives as well. At least the current ones.

Spare areas with decent copy on write and garbage collection see minimal benefit from TRIM.

 

[Yellowbeard]

I've been running RAID-0 with SSDs for 3 years or so. I've NEVER had any sort of slowdown that was noticeable in actual usage. You had to benchmark to test it and find any differences. This includes drives controllers of various makes including Indilinx, Samsung, and SandForce.

 

[VirtualLarry]

I've been running RAID-0 with SSDs for 3 years or so. I've NEVER had any sort of slowdown that was noticeable in actual usage. You had to benchmark to test it and find any differences. This includes drives controllers of various makes including Indilinx, Samsung, and SandForce.

I find that hard to believe. Until Intel finally released their RAID drivers with support for TRIM in RAID-0 configs, it was a risky proposition (as far as long-term performance was concerned) to RAID-0 some SSDs.

I tried it with some 30GB Agility (Indilinx) with 1.7 firmware, and after a week, they degraded in performance to slower than a single drive.

 

[Zxian]

I tried it with some 30GB Agility (Indilinx) with 1.7 firmware, and after a week, they degraded in performance to slower than a single drive.

The amount of data written to a drive should have no impact on read performance. It will affect the future write performance if the drive is not given enough time to perform its internal garbage collection (which just about every SDD controller has now) or for TRIM to be applied.

I've also been running RAID0 on my SSDs for a few years now. The day-to-day writes that you do on your system drive are so small that TRIM is really a bonus feature. I haven't done any tweaks to move caches or turn off indexing or anything of the sort on any of my systems. If you are working in a scenario where TRIM is a requirement, you'd know about it and ensure that you have it.

 

[mrpiggy]

Windows built-in software RAID0 and RAID1 implemented using Disk Management utility "does" support trim to the raid and the SSD's do process the trim (at least M4's do, however there shouldn't be any difference with others). Unfortunately you can't boot off a RAID0 Win software RAID, only RAID1.

 

[Coup27]

I tried it with some 30GB Agility (Indilinx) with 1.7 firmware, and after a week, they degraded in performance to slower than a single drive.

Those drives were junk before you put them into RAID so that is not a fair test to compare against current generation drives. I had 2x Samsung 830's in RAID0 for a while and although I didn't think it was worth the effort and thought the other drive was better used elsewhere, I did not experience any slow down over time. You could say my system idles a lot as I don't really task it these days so enough GC time would have eliminated any problems a lack of TRIM would have caused.

 

[thepriceisright]

So to sum up what we have so far:

1. Trim is only supported in RAID 0, and currently only the on-board Intel RAID can do it.
2. Not sure yet but this looks to be unlikely.
3. Supposedly yes: anyone have any proof? Or at least a “Yeah I’ve done this and it worked” confirmation.
4. Follow Coup’s instructions.
5. (the write in question of GC being enough) GC should suffice if you use a SSD that has plenty of extra room.

To the OP: Ultimate lurker - joined in December 2003 and have 2 posts - with BOTH OF THEM IN THIS THREAD!!! WOW!!!

I suppose it's borderline creeper instead of lurker! I like to dedicate my time to one forum. The community on the other forum is great and it's one of the bigger review sites but I've come to terms with the fact that since the forum is so small you really can't learn much from it. If you have questions you might as well not bother asking.

 

[Cerb]

Are you saying that Intel supports RAID 1 only or RAID 1 and RAID 0 with TRIM?

Typo (maybe I should stop using the numpad...that's twice this week, on AT forums!). RAID 1 will have the same deterministic needs as other RAID levels, even w/o parity.

 

[Concillian]

Original Poster --

Bottom line is you don't have to worry about TRIM. Long story short is that it isn't even needed for modern drives. It's a software solution for 3 generation ago SSDs that had garbage collection issues. Any SSD you buy these days has significantly better garbage collection. Be sure your system is idle for ~30 minutes a week and you're all good, RAID, TRIM, whatever... doesn't matter.

How full the drives are has a larger impact on performance than TRIM or no TRIM.

 

[kbp]

Trim will only work in RAID-O on a Z77 board. It is not supported on any other chipset at this time. You can confirm this on Intel's website.

 

[VirtualLarry]

The amount of data written to a drive should have no impact on read performance.

I disagree. My RAID-0 degraded, not just write speeds, but read speeds also.

As the internal mapping tables get more complex, some drives slow down for reads.

 

[taltamir]

4. How does one really know if TRIM is working

How does one know any feature in your computer is working? Did you test to verify that turbo boost for your CPU is working? Did you test to ensure your ram is running in dual channel mode?

If you are using windows 7+, have an SSD that supports it and a controller that supports it then its working.

the fsutil thing is kinda pointless, it does not check to see if TRIM works, it checks to see if windows is configured to send trim (not even if windows is ACTUALLY sending trim, just if the configuration is set to on or off). The only possible way for it to be on off is if you or a software you ran disabled it explicitly. I have never spoken to anyone ever who ran fsutil and got a result of "off".
TRIM is sent regardless of drive detected, so even HDDs receive trim (which they ignore)

Original Poster --

Bottom line is you don't have to worry about TRIM. Long story short is that it isn't even needed for modern drives. It's a software solution for 3 generation ago SSDs that had garbage collection issues. Any SSD you buy these days has significantly better garbage collection. Be sure your system is idle for ~30 minutes a week and you're all good, RAID, TRIM, whatever... doesn't matter.

TRIM doesn't just affect speed, it also affects write amplification. And it still matters even with modern more aggressive GC algorithms.