[Qemu-devel] [RFC] configuring thin provisioning for drives

[Paolo Bonzini]

In order to finish the implementation of thin provisioning, we need to
add a -drive option to describe how guest discard requests are mapped to
host requests.

We have three possibilities:

- hide them and make them always succeed
- translate them to ANCHOR requests, i.e. mark the space as discarded
but keep it allocated (for XFS this is an XFS_IOC_ZERO_RANGE ioctl; for
devices we could get a new ioctl in the kernel).
- translate them to UNMAP requests, i.e. mark the space as discarded and
release it to the filesystem or storage.

ANCHOR requests are not yet implemented, but I believe we should plan
ahead and develop the feature as if they existed.

I'll call these "full", "anchor", "unmap".  Kevin pointed out to me that
you may need to control these at both the format and protocol levels,
which gives 9 possibilities.  At the API level there is no problem
supporting all of them, but what about the user level?

Having two switches makes it complicated to explain the effects, also
because:

- The protocol setting does not matter with fmt=full;

- fmt=unmap/proto=anchor doesn't really make sense.  It is the same as
what qcow2 currently does, except that you'll also get all possible
performance degradations coming from your filesystem.

This leaves these five possibilities:

fmt=full/proto=full             No discard support
fmt=anchor/proto=anchor         Keeps preallocated files preallocated
fmt=anchor/proto=unmap          Keeps metadata preallocated
fmt=unmap/proto=unmap           Fully thin-provisioned
fmt=unmap/proto=full            Current behavior of qcow2

The current default is full/full, because by default the guest-visible
devices do not have discard.  Once you enable discard-granularity=512,
the default becomes unmap/unmap for raw, and unmap/full for qcow2.

When we change the default to discard-granularity=512, the default will
have to be changed to full/full or anchor/anchor, with the others
selectable from the command-line.  Unfortunately, this means there is a
backwards-incompatible change for users that are _already_ using
discard-granularity=512.

So, the first question is what to use for the default.  I'm leaning
towards anchor/anchor.

The other question is: do we need all five?  And if so, how to call the
options?  Here is the best I could come up with:

fmt=full/proto=full         -drive provision=off
fmt=anchor/proto=anchor     -drive provision=full
fmt=anchor/proto=unmap      -drive provision=metadata
fmt=unmap/proto=unmap       -drive provision=thin
fmt=unmap/proto=full        -drive provision=reuse

Any opinions or improvements on the naming?

Paolo