Linus Torvalds (torvalds@linux-foundation.org) on 1/20/11 wrote:
---------------------------
>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.
>
That is simply handled by unmapping the LBA to PBA mapping.

>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.
>
You do not immediately need to write it to the any nv state, merely be guaranteed that it will not get lost on power loss.


>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.
>
Yes, poor implementations will always exist.


>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.
>
Except that TRIM increases stability of performance and increases longevity of the device.


>The concept of trim is fine. It's the implementation
>that sucks so much that it's not even funny.
>
Well certainly going from the draft spec of data is indeterminate to read as zero wasn't the most daft idea. No was sync operation of the actual command vs making it an async hint. From a specification perspective neither are ideal, but from a hardware perspective, both aren't major obstacles. In a properly designed device, the TRIM reply should take on the order of ms and in practice table lookup and update should be quick as well and be able to operate in parallel with other actions.


>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.
>
TRIM is not a hack. It serves a useful function and has real world impacts on both performance and longevity.



>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.
>
You are taking one case and applying it to all cases. For DBs you want to primarily extend drive life via under provisioning. But there are large classes of operation where TRIM does extend drive life without having to resort to under provisioning.


>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.
>
Performance upside is always limited. And it makes available PBAs ahead of the time that the drive would actually see that the PBAs are available. This allows the drive better opportunity to optimize timing and performance effects of the GC routines.


> 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 the GC and remapping won't significantly change over time as the actual design constraints are real and any margin you get in creasing SRAM/DRAM sizes will be eaten up by increases in storage size. So the approximate effect is that while people can do a little tinkering with things like mapping, they aren't magically going to be able to go to full mappings from partial mappings, etc.

So its an issue of cost. The only drives that doesn't have effects of (re)mapping are already using large scale capacitive power and full map tables. They also tend to be fairly expensive. The vast majority of the drives people will be using will utilize partial mappings and will benefit from TRIM because in cases where they don't get TRIM they will largely trade off performance for correctness.