gallier2 (gallier2@gmx.de) on 1/25/11 wrote:
---------------------------
>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.

If we ignore the SATA implementation overhead, the essential cost of TRIM is the cost of updating the FTL's mapping tables. Overwriting a used block is not really any more expensive than writing a fresh blank block because the invalidation of the old block mapping can be batch committed as part of the same operation as the write.

Now, the benefits of TRIM if the drive has fewer live blocks now than the all-time maximum are real. By letting a flash erase block sit around longer before re-use, the expected amount of live data which has to be recopied before it can be rewritten (write amplification) is reduced.

If the file system doesn't tell the drive about dead blocks, the FTL will waste the SSD's endurance copying around dead data.

To keep everything as simple as possible, an SSD-optimized file system should, along with not worrying about keeping blocks contiguous, maintain three levels of LBA allocation: live, dead, and TRIMmed (a.k.a. never used).

The FS should try to keep all block allocations within the live and dead LBA "working set". In the steady state, or if the file system is growing, no TRIM commands are needed.

However, if there is a lot of write traffic without the dead list ever going empty, then it makes sense to TRIM some of the dead list and return it to the drive.

This can be deferred as necessary to amortize the costs of the TRIM.

This requires a different sort of file system. Linus is quite right that in a file system optimized for rotating media like ext4, the pain is much more significant, and does not justify the gain.