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

[Kevin Wolf]

Am 06.02.2013 17:39, schrieb 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?

We can't make it one option with 9 choices. Nobody guarantees that we
have exactly two layers. One format and one protocol are the most common
case, but we'll get deeper block driver stacks, particularly after
actually using block filters instead of hardcoded magic in block.c.

> 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.

If anchor makes any sense on raw files, why wouldn't proto=anchor make
sense as well? You keep the allocations on the file system level in
order to avoid fragmentation and reallocation overhead there, but still
tell the FS that you're not interested in the data any more.

> 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.

Sounds reasonable to me. Either that or full/full.

> 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?

Split them up, and have a discard=[ignore|anchor|unmap] for each layer
in the block driver tree. For the moment I think it may be acceptable to
only configure the format and let the protocol inherit the same setting.
With -blockdev you get then access to the rest of the options.

Kevin