Linus Torvalds (torvalds@linux-foundation.org) on 1/20/11 wrote:
---------------------------
>iz (i@z.x) on 1/20/11 wrote:
>>>
>>>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.
>
>Bzzt, wrong.
>
>In fact, if your SSD does all writes sequentially, your
>SSD is incompetent. You have several chips on that SSD,
>and even with a single chip you may well have several
>channels within the chip and if the chip also contains a
>controller, those channels may actually be available.
>
>And your controller - if it is any good - should very much
>be exposing those sources of parallelism. Only the bad ones
>think that writes are sequential.

Yeah, yeah, but just like CPU instruction ordering, it's about apparent order, not real execution order.

So of course the drive writes things in parallel, but at any point in time, it should look like all writes were handled sequentially.

>>>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.
>
>Sure. But that's not a huge advantage, since it's mainly
>about avoiding the DMA and the wire cost. And since the
>alternative is not "send zeroes", but instead the
>simple "do nothing at all", it means that from an actual
>usage standpoint, sending a TRIM command is absolutely not
>"free". It's a real expense.

Yes, but it can save a lot of unnecessary work for the drive later. It very much depends on the IO pattern what works out the best in the end.

>At a minimum it eats one of the (precious) command tags,
>and that's the good case. In the bad case, it ends
>up serializing all the writes (the thing we really
>actually care about) that are going on at the same time.

Those command tags aren't that precious. Maybe for heavy server loads or other easy cases like big file transfers, but the slow case is synchronous reads with no other IOs outstanding, or (almost) synchronous writes. If you throw enough commands at it the drive has enough room to hide its latency problems.

Anyway, if the TRIM was tagged onto normal write commands it would cost no extra command overhead. Even with the current TRIM you can do a lot of TRIMs with one command. The real cost would be the extra mapping table update.

>Remember: the machine isn't actually just doing TRIM
>commands. The system is doing real work. TRIM is the
>extra expense that isn't even real work, and ends up
>easily being the thing that actually slows down the things
>the user actually cares about.

I'm more worried about the extra CPU overhead caused by the extra processing by the firmware on the SSD itself, assuming a good implementation.

But if the file system manages to (eventually) overwrite all deleted blocks I agree that TRIM isn't really worth it in most cases (with big file deletion being the exception).

>Anyway, I'm just trying to explain why TRIM is disabled
>by default in any sane setup. And I'm trying to hammer home
>the "TRIM isn't _that_ important" message.

That is certainly true.

I'm writing a decent FTL and it's optimised for random IO and low latencies. TRIM is very low on the list.