I've been looking into the ATA piece of this (at Dave's request). Part of the problem is that
the ATA TRIM command isn't fully specified yet, so we'll need to allocate a temporary command
to test it. This also means that no existing device on the market can take advantage of it.
Another part of the problem is that the way we handle ATA these days is through the SCSI
layer. So in order to implement the ATA TRIM command, we first have to implement the SCSI
PUNCH command. The SCSI PUNCH command is a very complex beast. It allows you to specify all
kinds of things that ATA (and indeed Linux) don't let you do, and as a result is a pain to
implement. I'm negotiating with T10 to attempt to get PUNCH simplified, but not having much
luck so far.
It's a SMOP but I have more urgent projects right now. One of them is ata_ram, which (not
entirely coincidentally) today grew the ability to do lazy allocation of the memory pages it
uses as its backing store. Once that feature's debugged, supporting TRIM should be feasible,
then I'll have motivation to get back to implementing PUNCH.
Posted Aug 14, 2008 17:27 UTC (Thu) by GreyWizard (subscriber, #1026)
[Link]
This also means that no existing device on the market can take advantage of it.
What about virtual machines? At present once a block is allocated on a dynamic disk the host has no way to know that it can later be discarded, even if almost every file in the guest is deleted. Isn't this exactly the same problem? Changing the software that emulates an ATA device could probably happen more quickly than hardware changes.
Block layer discard requests
Posted Aug 14, 2008 17:42 UTC (Thu) by willy (subscriber, #9762)
[Link]
You're quite correct that a virtual machine could make some use of it. If we have an
interface to the filesystem that allows us to punch out blocks (see eg
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?co...) and use sparse files, we could "overprovision".
The software that emulates an ATA device can probably be changed about as quickly as real ATA
devices -- remember drives are full of firmware too. The holdup is getting T13 to decide on a
command number and publish ATA8. Then it's a 'simple matter' of getting users to upgrade ...
and I think a large number of them are going to be wary about further updates from at least
one major virtualisation provider from now on.
Oh, of course drive vendors aren't typically quick to publish microcode updates. You've
already bought the drive, so they have little to gain from giving you firmware updates, and as
every firmware update is potentially dangerous, they have a certain liability there too.
Block layer discard requests
Posted Aug 14, 2008 19:09 UTC (Thu) by GreyWizard (subscriber, #1026)
[Link]
That makes sense. Thanks for the extra information.