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

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

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.

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.

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.

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.

Linus