Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>So the problem with asynchronous TRIM is that it gets really
>quite scary when you decide you want to use that block you
>just trimmed for something else (ie a new file allocation).
>
You mean the physical block that you don't and never had any control over? All TRIM does on a drive is go through the logical to physical mapping process and mark the physical block as free but dirty. The only interface you have to the device is the logical block interface.

You NEVER have control over the physical block. On an SSD every write will allocate a new physical block from the free and clean list. If there was a previous logical to physical mapping for the logical block you wrote, it will mark the previous physical block as free but dirty.

The ONLY thing that can scrub a free but dirty block to free but clear block is the drive itself.

In fact, the operation that occurs when you issue the TRIM command is the same thing that happens to the old mapping when you issue a write command to a logical block that is already mapped.

TRIM is:
MAP_LOGICAL_TO_PHYSICAL(Log_Addr, Phy_Addr, Hit)
if Hit then MARK_PHY_ADDR_FREE_AND_DIRTY(Phy_Addr)


WRITE is:
MAP_LOGICAL_TO_PHYSICAL(Log_Addr, Phy_Addr, Hit)
if Hit then {
MARK_PHY_ADDR_FREE_AND_DIRTY(Phy_Addr)
GET_FREE_AND_CLEAN(New_Phy_Addr)
UPDATE_LOGICAL_ADDR(Log_Addr, New_Phy_Addr)
WRITE_PHY_ADDR(New_Phy_Addr, Data)
} else {
GET_FREE_AND_CLEAN(New_Phy_Addr)
UPDATE_LOGICAL_ADDR(Log_Addr, New_Phy_Addr)
WRITE_PHY_ADDR(New_Phy_Addr, Data)
}

This fundamentally means that if TRIM is broken, then the write flow is EXTREMELY suspect!


>So it doesn't really work, and in practice you need to
>see TRIM as being pretty much 100% equivalent to a write
>command. So it's not just "send 8 bytes to the disk", it
>basically ends up being 100% equivalent to a "write zeroes
>to these blocks".
>
It is a header and a list of LBAs/LBA ranges.



>In practice, that almost certainly means that you're
>better of just doing the overwrite in the first
>place - ie never sending the TRIM at all, and instead
>just aggressively re-using the free'd space for new writes.
>
but you can't because you only interface with the logical block interface and have no control/interface with the physical block interfaces.


>Which is why TRIM is not at all a simple thing. There is
>no "obviously correct answer", except for the one that says
>that it's damn complicated, and there are lots of disks
>that do really really bad things with TRIM commands.
>
Um, with SSDs it IS pretty obvious!