Aaron Spink (aaronspink@notearthlink.net) on 1/20/11 wrote:
>
>Can we agree that if the SSD does anything but either ignore the TRIM command or
>merely mark the PBA to free but dirty, it is probably a bad design?

Umm, Aaron, I don't think you understand the complexities.

TRIM (these days) has real semantics: it guarantees that
the block will read back as zero. Now, part of the problem
is that there is historical baggage that does not
guarantee that, but that's historical and broken.

So no, you can't just ignore the command. As an SSD, you
have the choice to say that you don't support it at all
and error out, but it's not a no-op.

And no, you can't just "merely mark it free" either. It
needs to be marked free _stably_, so you need to actually
write it to the long-term translation map, not just set
a bit in your RAM cache. Depending on just how that one is
set up, that can be quite complex and end up triggering
your GC cycle or whatever.

End result: you'll find several SSD's that are either
actually buggy and will corrupt or brick your drive, or
(more commonly) you'll find SSD's for which TRIM will be
extremely slow and synchronize everything, the way a
write does, because what they do is actually very close
to what they do for a write.

(And as usual, it's often a "depends on the exact case"
thing - iow you may well have just the occasional
huge latency spike because it depends on whether it ended
up forcing a synchronous GC event).

The ones that do TRIM well are usually the ones that do
regular writes so well that you don't really care
about TRIM in the first place, as they do good GC and do
it in the background.

>Unfortunately, considering Linus' hatred of the existence of TRIM and considering
>he is a smart guy, the only logical conclusion I could come to was that he didn't
>fully understand the underlying hardware

I understand the hardware. The problem is, you don't. You
only understand the concept. Or maybe you're one of
those people who understand the flash hardware at a cell
level, and are usually the least informed about the actual
end results (because they don't understand what a realtime
GC really entails, but only concentrate on the "you need
to not write the cell too much" problem).

The concept of trim is fine. It's the implementation
that sucks so much that it's not even funny.

"In theory, practice and theory is the same, but in
practice, they aren't"

and it's not actually TRIM I despise as much as I despise
some of the people who push TRIM. They really often are
the same people who pushed the "you need to do writes in
64kB-aligned chunks of 64kB, because SSD's are basically
flash and the erase block.. derp derp derp".

They were wrong. TRIM is a hack, and it should be seen as
such. It should be seen mainly as a way to allow slightly
more efficient GC, and as a way to prolong the life of
the media a bit. But even then, if you think TRIM is
somehow "fundamentally important", you're WRONG.

Even the "it extends the life of the media" argument is
TOTAL AND UTTER CRAP! Why? Because you can never guarantee
that TRIM will happen anyway (think databases: they do lots
of writes, and they overwrite their preallocated
database, there is never any TRIM going on), so your
lifetime calculations need to be done without any TRIM in
any case. So it has absolutely zero practical result.

And the performance upside is limited. The only real upside
you should ever see is that it extends the extra space that
the SSD has for GC anyway (usually in the range of 10% of
the actual flash capacity), and that can make the GC
algorithm able to do a better job of remapping blocks. But
that's a rather small incremental improvement unless your
GC sucked to begin with.

See?

This is why I detest TRIM as a practical feature that has
been oversold way too much by people who don't understand
the practical details. It's simply not as important
as people claim it to be. You cannot and mustn't rely on
it, and if it makes a huge difference in performance, all
that really tells you is that the GC and remapping of the
drive sucked to begin with.

And it really is problematic. It's slow and unreliable in
practice. It's by no means instantaneous, even in the good
cases.

So right now - and likely for the next few years - the
downsides of TRIM outweigh the upsides.

You don't understand that, because you think of TRIM as
some conceptualized ideal. While I think of it as an actual
practical detail. In your conceptualized world, there are
no downsides.

Linus