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

[Paolo Bonzini]

Il 06/02/2013 19:37, Kevin Wolf ha scritto:
>> 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.

Thinking more about it, it's really about data and metadata more than
format and protocol.  A format will always look only at the metadata
option, but a protocol may consider both.

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

proto=anchor still keeps some reallocation overhead since you have to
mark the extent as written.  So you could use anchor/anchor (and
preallocate) if you don't want any fragmentation; or use unmap/full if
you want to avoid all filesystem overheap.

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

Ok.

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

I thought the same, the problem here is that we risk a regression for
those who were using qcow2 (effectively in unmap/full mode) with an
inefficient filesystem, and we have no way to fix it except by disabling
thin provisioning.

If there is no such user (not unlikely...), we can sure go this way.

Paolo

> With -blockdev you get then access to the rest of the options.