Re: [PATCH 2/3] nbd: Add new qemu:allocation-depth metacontext

[Eric Blake <eblake@redhat.com>]

On 9/26/20 2:33 AM, Richard W.M. Jones wrote:
> On Fri, Sep 25, 2020 at 03:32:48PM -0500, Eric Blake wrote:
>> +The second is related to exposing the source of various extents within
>> +the image, with a single context named:
>> +
>> +    qemu:allocation-depth
>> +
>> +In the allocation depth context, bits 0 and 1 form a tri-state value:
>> +
>> +    bits 0-1 clear: NBD_STATE_DEPTH_UNALLOC, means the extent is unallocated
>> +    bit 0 set: NBD_STATE_DEPTH_LOCAL, the extent is allocated in this image
>> +    bit 1 set: NBD_STATE_DEPTH_BACKING, the extent is inherited from a
>> +               backing layer
> 
>>From the cover description I imagined it would show the actual depth, ie:
> 
>           top -> backing -> backing -> backing
>   depth:   1        2         3   ....          (0 = unallocated)
> 
> I wonder if that is possible?  (Perhaps there's something I don't
> understand here.)

The real reason I don't want to do a straight depth number is that 
'qemu-img map' combined with x-dirty-bitmap is still a very convenient 
way to get at bits 0 and 1 (even if it requires decoding).  But if we 
plumb in a way for bdrv_get_status to return depth counts (rather than 
reimplementing the depth count ourselves), I would have no problem with 
returning a struct:

bits 31-4: the depth of the chain
bits 3-2: reserved (to make reading hex values easier...)
bits 1-0: tri-state of unalloc, local, or backing

where it would look like:

0x0000 -> unallocated
0x0011 -> depth 1, local
0x0022 -> depth 2, from the first backing layer
0x0032 -> depth 3, from the second backing layer
0x0042 ...

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org