Now that I've rebuilt my main Linux server, added a 120GB Intel SSD and converted all the file systems to XFS, I've gotten interested in the internals of both XFS and TRIM and how they work together (or will work together). I'd like to know exactly how the drives implement TRIM but I've only found bits and pieces. Can anyone suggest a current and complete reference for the complete SATA command set that includes all the TRIM related stuff? As I understand it, there's a SATA (and SCSI?) command that will repeatedly write a fixed block of data to some number of consecutive LBAs (WRITE SAME), and an "unmap" bit in the write command can be set to indicate that instead of actually writing the blocks, they can be marked for erasure and placed in the free pool. Is this the only way it can be done? It occurs to me that while an "unmap" bit should be quite fast, you don't absolutely *have* to have it. Just have the drive interpret an ordinary write of all 0's to any LBA as an implicit "unmap" indication for that LBA. As long as the drive returns all 0's when an unmapped LBA is read (and I believe this is already a requirement) then were an application to write a block of real data that just happens to contain all 0's, it would still get back what it wrote. Then you could manually trim a drive with something like dd if=/dev/zero of=foobar bs=1024k count=10240k rm foobar or if you're really adventurous and don't mind a little hiccup: dd if=/dev/zero of=foobar bs=1024k count=20m rm foobar (i.e, let dd run the file system out of space before you delete the temporary). Then you wouldn't need a potentially dangerous program like wiper.sh talking directly to the drive behind the file system's back. And while wiper.sh only works with file systems whose structures it knows, this approach would work with ANY file system. This will all become moot when every SSD supports TRIM and every file system uses it. But there are a lot of file systems out there, not all of them support TRIM, and many may not for some time. Somebody must have already thought of this, right? Phil _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
