TRIM details

[Phil Karn <karn@philkarn.net>]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs