>>>>> "Phil" == Phil Karn <karn@xxxxxxxx> writes: Phil> Oh, there's no question that an explicit TRIM command would be Phil> *far* more efficient than an implicit TRIM that writes zeroes. If Phil> nothing else, implicit TRIMming requires writing every single Phil> sector individually, while the WRITE SAME command lets the host Phil> wipe up to 65,536 (I think) sectors with a single command. ATA does not have WRITE SAME. It's a SCSI command. WRITE SAME(10) allows clearing 32MB per command on a device with 512-byte blocks. WRITE SAME(16) allows a bigger area but most drives don't support it. Those that do often cap at 16-bits anyway (Note that I'm talking about drives. Arrays are more flexible). DSM TRIM allows you to clear 2GB per command with a 512-byte payload. Several modern drives will let you clear 16GB with a 4KB payload. Phil> But that's not my point. My point is that if the drive could Phil> recognize a write of 0s to a sector as an implicit TRIM, then it Phil> would still be possible to manually trim the drive without any Phil> support whatsoever from the device driver or file system. But the fact remains that drives don't implement this. They do implement DSM TRIM. Even if the drives did support zero detection we'd have no way of getting the information to them short of sending a bazillion zeroes down the pipe. And why would the drive vendors add support for a crappier interface when DSM exists? If you are set on using dd you could do zero detection in the kernel and have the filesystem either send the data pages or issue discards for the relevant regions if the device supports it. We pretty much have all the infrastructure in place for that. But your time is better spent adding FITRIM support to your filesystem of choice. XFS is done already, Christoph posted the patches. Phil> I don't think it would be that hard for the drive to recognize a Phil> write of all zeroes. It already has to compute a set of Reed Phil> Solomon parity symbols for every block written to the Phil> drive. That typically happens way later. There's usually a clear separation between command processing and encoding. The zero detection needs to happen early as it affects whether you need to mark the block in a bitmap or allocate a real flash block. -- Martin K. Petersen Oracle Linux Engineering _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs