Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>No it isn't. Not even close. You can try to make an analogy,
>but the fact is, TRIM and "free()" have absolutely zero
>points in common.
>
They have a lot in common. All the TRIM command does is inform the device that the logical block(s) are no longer in use. The device can ignore it, it can immediately reuse the physical block, or it can simply mark physical block invalid in its map table.


>In many ways, TRIM is closer to "unmap()" or a shrinking
>brk(), and if you actually were to look at most malloc
>libraries, they will go to quite some length to never
>actually use unmap or shrink the heap using brk().
>
And an SSD in many ways operates like a malloc library. You sending a TRIM command to the SSD doesn't make it do anything. It can totally ignore it (which is something that a malloc library generally can't) or it can just like a malloc library mark the corresponding physical block as available for future use. It does have to do any operation on the actual NAND at that point. It just adds it to the list of blocks that are free but dirty. At its leisure, it can clean and reuse those physical blocks or any other physical blocks. The only other way that a physical block gets marked free but dirty is if you write its corresponding logical block.

So by using trim you make available more physical blocks for reuse which allows the SSDs to do a better job at GC and a much better job at wear leveling and always results in as good if not better performance.

The only thing I can think of is that you are assuming that the SSD has to do some physical operation on the NAND when you send a TRIM command. It doesn't. All the TRIM command does is update the mapping tables.

>Why? Because it's damn slow. The libraries know that it's
>better to use do their own freelist management, and rather
>than give the memory back to the OS, just re-use it.
>
TRIM isn't slow. It is a small command on the SATA/SAS/FC bus.

>The exact same case is true of trim. In normal operation,
>you're better off just managing and re-using the disk
>yourself, rather than wasting your time informing the
>disk about your usage patterns.
>
You cannot manage and re-use the disk yourself. You have no idea and no control over the logical to physical mapping.

>That is a closer analogy. Don't do it at run-time,
>because there is absolutely no reason to do so. You can
>do it for when somebody frees gigabytes of data in one go,
>but you're much more likely to do it offline (ie when the
>process exits and is no longer doing any malloc/free at
>all).
>
The drives don't have to take any immediate action based off a TRIM command. It is merely informational. The actual data movement and remapping can happen whenever the drive wants to.


>Btw, while I think my munmap analogy is much better than
>your totally idiotic free() one, I also wouldn't claim that
>my analogy is all that great either. The use cases are
>different, and you'd never expect to have to worry about
>unmap/brk failing the way TRIM fails.
>
Do you have a list of drives that TRIM fails on?