The tricky bit of TRIM is that it depends on the SSD controller/firmware implementation. So you can't assume a perfect TRIM implementation and hence can't use general rules for when or how to do TRIM.

That said, for a perfect TRIM implementation the follow holds:

Ungo (a@b.c.d.e) on 1/25/11 wrote:
---------------------------
>1. You should never TRIM unless the SSD is otherwise idle, because sending a TRIM has costs similar to a write.

Or interleave small TRIMs with regular writes. That way the TRIM info can be stuffed in the page metadata and almost no extra IO is caused. But you can't count on SSDs doing this, so better to batch them up.

Idle or not has no influence, because if you batch TRIMs up the performance decrease should be minimal enough that it doesn't matter.

>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?

Exactly. That's why it's much better for file systems to reuse blocks instead of TRIMming them.

>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.

True, but you could get into trouble with a very fragmenting IO pattern (like writing big files and then overwriting the deleted space with random writes, and this often enough that it has a global effect on GC efficiency).

So if you can't be really troubled with TRIM, only use it on big blocks just freed to avoid future fragmentation.

>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.

Thing is, even if you TRIM random 4kB blocks all over the place, a thousand of those fit in one NAND page. So just flush the list every 1k entries and the write overhead caused can be minimal.

That said, the cost of updating the mapping table and extra CPU usage to handle all the TRIMs is real, so TRIM will never be free, but the cost can be reduced to at most 10% write speed decrease (assuming a 10% write amplification for regular writes). For a TRIM to be effective it only has to prevent one page from being GCed unnecessarily every few hundred TRIMs.

>
>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.

No, because there's a limit on how much you have to batch up to get minimal overhead. But re-using blocks is probably easier for a FS than getting TRIM right and generally a lot better too.

>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".

Yes, because when you would notice a huge difference, you hit the garbage collection bottleneck and that's something you never want to hit (because it's always slow).

That doesn't mean the FS can't help to avoid that. In order of importance:

1) Use a SSD friendly block allocation algorithm.

2) Use TRIM when it makes sense.

Between hitting GC limits and not noticing any difference is also the wide gap of the disk doing less efficient GC, causing less endurance and more power usage. But this isn't something you can easily measure, and when you do 1) it's already a lot less likely.

>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.

Very true!

The FS can give the SSD more breathing room by virtually increasing the reservation size, which helps a lot more than TRIM. So it should use as few blocks as it needs and leave the rest untouched (in case of the FS getting significantly less full, it should use TRIM to "give back" the unused space).

>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.
>

It isn't and can't be. If the filesystem is SSD friendly, then TRIM doesn't add much and only makes sense in a few rare cases.

TRIM only helps for when data is freed and not reused soon, so it has time to be be GCed for nothing. The latter is unlikely because there are usually more free blocks, and the first is unlikely because disks generally fill up with more, not less data.

That said, there is absolutely no excuse for SSD controllers to not get TRIM right, and even if a FS uses TRIM all the time, the degradation should be at most 10%. Any controller that slows down much more than that is crap.