|
From: | Eric Blake |
Subject: | Re: [PATCH 2/3] nbd: Add new qemu:allocation-depth metacontext |
Date: | Mon, 28 Sep 2020 09:33:22 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
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 layerFrom 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
[Prev in Thread] | Current Thread | [Next in Thread] |