Anon (no@email.com) on 1/24/11 wrote:
---------------------------

>Without TRIM, a disk must assume any sector ever written to still contains valid
>data - it CANNOT assume otherwise (unless the FS is going to be implemented in the controller..).

The problem seems to be that whoever wrote the specification
for TRIM goofed. The specification should have been that
TRIM would leave the contents of the TRIM'ed sectors
undefined. That would have given the controller the
freedom to either a) completely ignore TRIM, or b) implement
it in a simple asynchronous way, just putting the sectors/blocks into a queue for future erasure.

Instead they defined it in such a way that the sector *does*
still have to contain valid data. Which is rather hard to
do: so various disk manufacturers choose to not implement
it at all, have a correct but slow implementation, or
implement it in a complex but buggy way. Presumably a few
get it right. But as Linus says, it's pretty much useless
as long as a significant proportion of disks do it
slowly or incorrectly.

The idea makes sense. But the details got irretrievably
screwed up. And I don't know why: free() isn't defined
to overwrite the free'd block with zeros. And it would be
obviously slower if you forced it to do that.