Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>The fact is, any SSD worth anything should work perfectly
>fine without trim, and if you need trim to get it back to
>good performance, you should just ditch the SSD entirely.

Yes. But if there was good TRIM support then it would work even better, because it wouldn't get into the bad performance state in the first place.

It's sad that TRIM is supported badly and that the command is a serializing one. So yes, you had bad experience with TRIM, but that doesn't mean the concept is wrong, just the current implementations (both on SATA protocol level and in SSDs).

If you fill up your disks with gigabytes of data and later remove that data, the next time you write a lot, would you prefer it to happens as fast as possible, or half the speed?

Not only that, but while writing the new data you get high latencies for unrelated reads, while you wouldn't if you had TRIMed the deleted blocks.

Extreme example: You write a 100GB file, delete it, and overwrite those blocks randomly with new data. Without TRIM the disk will be forced to GC those deleted data to find room for your new writes, while if you had TRIMed the data it knew it could just reuse it and doesn't have to salvage it.

So get yourself a spare SSD with good TRIM support and do the above test and see what the performance difference is.

Good TRIM may not be very noticeable in day to day live, but it would avoid the worst case performance a lot more often. Suboptimal TRIM implementations lower peak performance, but should still have better average performance. TRIM reduces the number of unnecessary data written to the disk caused by GC'ing deleted blocks.

>
>The whole "SSD's need TRIM" support was a bedtime story for
>gullible morons. The same morons who also bought the "SSD's
>need big IO and natural alignment" story that came out a
>couple of years before that.

Same story with natural alignment: A good drive doesn't need it, but even then it's better to have it. Even if the performance is the same for both cases, the power usage of aligned IO should be less (a lot less for tiny unaligned random reads).

I find it funny that you rave about buggy handling of TRIM in SSDs, but have enough faith that they'll get unaligned IO right. In my opinion implementing good TRIM is easy, but handling unaligned IO as good as aligned IO quite hard (in case of same alignment for the read as when the data was written). Just because it has more corner cases.

>In fact, even when it's not really slow (and when it's not
>buggy), it still makes a normal file deletion much more
>expensive, since normally you'd just throw the blocks away
>without doing any IO at all. Doing even a fast TRIM is thus
>infinitely more expensive.

If you take a very short-sighted view, yes. But see above.
You have to choose between "slower delete now" and "much faster writes later".

With a good TRIM implementation, both on the protocol level and SSD level would make it possible to issue one TRIM command to trim an arbitrary range of blocks at once, and it would cost no performance at all.

>
>Finally, the whole saga has been further complicated by
>historically bad specifications ("does it leave the data
>in a known state") and by the fact that certain uses really
>need the TRIM area to be really big and really aligned (ie
>the whole non-SSD RAID use of TRIM wants it to cover whole
>stripes, so you want TRIM commands to be naturally aligned
>and megabytes in size).

Yes, that is unfortunate and it's probably best to have different TRIM commands depending on their purpose.

> And in reality,
>you'd want it to be an off-line feature, ie something akin
>to doing a defrag event, rather than something you do as
>part of a normal filesystem operation.

Actually, the exact opposite is the case. You do want to issue TRIM commands together with normal IO commands. This because there is no reason to delay telling the drive that it doesn't have to GC deleted data, and because if you don't make it part of normal IO, you end up with a huge batch of blocks to TRIM, and just issuing all those TRIMs suddenly takes a lot time, no matter how fast a single TRIM is.

Of course, this needs proper TRIM support which is missing at the moment. In my opinion every write command should have space for a TRIM to hitch-hike with it, because usually ever write replaces some other data, besides the blocks just written to. Drives have to guarantee that such TRIMs only make it after the data is written. This way you can have TRIM support with zero cost and all the upsides.

>Maybe the above will change eventually, but right now
>TRIM is totally oversold, and totally pointless. Just don't
>even bother with it. Do your SSD comparisons after you've
>done lots of random writes, and expect that in real life
>the time when an SSD can optimize its GC i when you do nice
>large file writes. Not when you TRIM things.

Writing a big file or TRIMing the same area should have the same effect for GC. If not, the TRIM implementation is crap.

Try your test the other way round, first writing a big file and then overwriting it with random writes. Without TRIM your drive will be limited by GC speed, assuming the file was big enough and causes enough GC pressure. With TRIM there is no need for GC, because the free blocks can be reclaimed directly. (This is probably also a good test to see if the drive has good or bad TRIM support.)