On 1/7/11 1:11 AM, Matthias Schniedermeyer wrote:
> The drive would have to look into each written sector in the off chance
> that it might be 0, that's a lot of electrons you have to burn for not
> much gain. And that's ignoring the performance side, doing such a check
> on each incoming write would be expensive at best.
Oh, there's no question that an explicit TRIM command would be *far*
more efficient than an implicit TRIM that writes zeroes. If nothing
else, implicit TRIMming requires writing every single sector
individually, while the WRITE SAME command lets the host wipe up to
65,536 (I think) sectors with a single command.
But that's not my point. My point is that if the drive could recognize a
write of 0s to a sector as an implicit TRIM, then it would still be
possible to manually trim the drive without any support whatsoever from
the device driver or file system.
You could use a standard copy command, provided you have something like
/dev/zero, or you could write a simple application that wouldn't even
need root privileges (assuming it didn't need to get around any quotas
when creating the temporary file). And it would work for any file system
and any operating system while we're waiting for native TRIM support
(I'm still waiting for TRIM support for HFS+ in Mac OSX).
I don't think it would be that hard for the drive to recognize a write
of all zeroes. It already has to compute a set of Reed Solomon parity
symbols for every block written to the drive. That's quite a bit more
work than merely seeing if the block is all 0's.
You could even use the existing Reed-Solomon encoder to optimize the
process though I doubt it would really be necessary. The RS parities for
an all-0 data block are also all 0. If any of the parities are non zero,
then it can't be a block of 0's. If the parities are all zero, then
confirm in software that the data is all 0's; you'll have very few false