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 alarms. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
