Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>iz (i@z.x) on 1/19/11 wrote:
>>
>>The thing is, the SSD should do it offline. A TRIM should be just informative and
>>asynchronous. It's what, 8 bytes of info? Really, a good TRIM implementation should
>>be practically free, both in command overhead and performance. The SSD should tuck
>>it away and use the info when it needs to do GC.
>
>So the problem with asynchronous TRIM is that it gets really
>quite scary when you decide you want to use that block you
>just trimmed for something else (ie a new file allocation).

Depends on what guarantees the drive gives. If it guarantees that all writes (including TRIMs) are handled sequentially and aren't reordered (especially not after unclean shutdowns), I think nothing much scary is left. And there is absolutely no reason to not guarantee this for SSDs, except incompetence.

>So it doesn't really work, and in practice you need to
>see TRIM as being pretty much 100% equivalent to a write
>command. So it's not just "send 8 bytes to the disk", it
>basically ends up being 100% equivalent to a "write zeroes
>to these blocks".

Yes, this is how I conceptually see TRIM. The only difference is that you're not sending all those zeroes.

To avoid the command overhead I'd lump it with normal write IO to make it really cheap to issue TRIMs.

>And by that I mean that you also end up having to wait
>for the end result etc, so it's effectively serializing
>and it's going to make your file delete operation slower.

With current SATA the TRIM command is serializing, so yes, you have to wait. But you have to wait very shortly because no real IO happens to complete it.

>In practice, that almost certainly means that you're
>better of just doing the overwrite in the first
>place - ie never sending the TRIM at all, and instead
>just aggressively re-using the free'd space for new writes.

That is good to do anyway, but file systems like to avoid fragmentation too, so there's a limit to how aggressive you can be with overwriting. To avoid unnecessary GC it's still best to use TRIM, but the need for it is much less when overwriting a lot.

>But to make it all even more interesting, it's obviously
>going to depend a lot on the exact behavior of the GC in
>the drive, as well as the particular IO patterns of
>the filesystem in question.

Yes, as well as the FTL implementation, because doing TRIMs has accounting overhead.

>Which is why TRIM is not at all a simple thing. There is
>no "obviously correct answer", except for the one that says
>that it's damn complicated, and there are lots of disks
>that do really really bad things with TRIM commands.
>
>End result: for the immediate future, you're likely best
>off just not touching that particular sticky wicket. It's
>going to be years until you can more or less depend
>on disks getting it right.

True, that's why I think a new TRIM command is needed. It should basically say "I'm a sane drive doing TRIM for almost free, hit me".