Richard Cownie (tich@pobox.com) on 1/25/11 wrote:
---------------------------
>
>Since hardly anyone uses it, and yet a lot of SSDs work
>just fine, evidently it isn't "needed". What matters
>for managing wear levelling etc is the ratio of used
>blocks to blocks-the-SSD-controller-knows-are-free.


Just a question, as an uninitiated in the magic of SSD. How does the SSD firmware determine if a logical block is free or not, without knowing something from the used file system?
Without some voodoo magic (i.e. layering violation) it can not.

I suppose, the idea of Linus is that it doesn't matter, as it will be overwritten anyway sometime later, the firmware will have to remap that logical block anyway to a new physical block, the old physical block is then free for GC. So even if your file system supports TRIM when freeing sectors, you will still need to do it implicitly when updating a block. So you cannot remove the hidden trim on write functionality.
This means that your SSD firmware ends up trimming exactly the same number of times, it's only the moment it will be done that differ. This means, if you don't want the trim command to serialize and delay your writes, you have to cache them for later, which the firmware already has to do.

So, sorry that in the end I answered my question myself, but thinking about the problem from the firmware side made me realize that Linus is right: TRIM is more than useless, adding complexity and overhead for something the firmware already has to do.