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
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
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
Then you could manually trim a drive with something like
dd if=/dev/zero of=foobar bs=1024k count=10240k
or if you're really adventurous and don't mind a little hiccup:
dd if=/dev/zero of=foobar bs=1024k count=20m
(i.e, let dd run the file system out of space before you delete the
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?