David Kanter (dkanter@realworldtech.com) on 1/25/11 wrote:
---------------------------
>I don't know how ext4 implements
>TRIM, or how that compares to other FSes. I do know that one of my friends who
>does a lot of work on FSes does not have a high opinion of SSDs and thinks that
>they are mostly unproven (although this was several months ago).
>
>I wonder how other FSes do with SSDs in general and TRIM in specific.

I don't think I'm really stating anything which hasn't already been covered in some way on this thread, but let me try to summarize some principles.

1. You should never TRIM unless the SSD is otherwise idle, because sending a TRIM has costs similar to a write.

2. You should never TRIM anything you're about to overwrite, because an overwrite is more or less the same as TRIM+write, and why use 2 operations when one will do?

3. It probably isn't all that important to TRIM everything you deallocate. If the drive's firmware is solid it should get by just fine if you never send a single TRIM. If it isn't solid, you have other problems.

Given these 3 principles, the best implementation is probably something which pushes deallocated LBAs into a "to-be-trimmed" list which is kept only in volatile memory. Then you need a background maintenance thread to fire up during periods of low I/O activity and work its way through the list.

When the FS needs to allocate blocks, it may be valuable to remove LBAs from the TRIM list and overwrite them instead. If there aren't enough blocks (or no single extent large enough to fill the allocation), fall back to the normal FS allocation algorithm.

It should be ok to drop things from TRIM list without actually doing anything. In fact, it's probably even desirable: if you tried to obey the principle of not TRIMming during heavy IO, and tried to keep track of everything ever added to the TRIM list, you'd end up with a kernel data structure which grows almost without bounds. Keep it small, drop old entries if new ones fill the table.


Overall it looks like the same sort of nigh-impossible optimization problem as paging -- that is, the theoretical ideal behavior is only possible to achieve by accurately predicting future application behavior.

Unlike paging, however, it's not clear that there are huge gains to be had by getting it approximately right. The benefits are small. It almost seems to be the case that it's more a matter of "how do I get performance back to the same level it was before I decided to implement TRIM".

In fact, I think the part about preferentially reusing recently deallocated LBAs might be much more important than actually TRIMming them. It gets you the benefit of TRIM as a side effect of something you're doing anyways. You only want to TRIM deallocated blocks if you don't have an immediate need to allocate a block.

I haven't seen any convincing argument yet that Linus isn't right on his central point that TRIM has been massively oversold as a vital thing to implement if you want to use SSDs. It just isn't.