[Libguestfs] [RFC libnbd PATCH] info: Add support for new qemu:joint-allocation

[Nir Soffer]

On Thu, Jun 10, 2021 at 4:06 PM Eric Blake <eblake at redhat.com> wrote:
>
> On Thu, Jun 10, 2021 at 01:20:13AM +0300, Nir Soffer wrote:
> > > +  else if (strcmp (metacontext, "qemu:joint-allocation") == 0) {
> > > +    /* Combo of base:allocation and stripped-down qemu:allocation-depth */
> > > +    const char *base, *depth;
> > > +    switch (type & 3) {
> > > +    case 0: base = "allocated"; break;
> > > +    case 1: base = "hole"; break;
> > > +    case 2: base = "zero"; break;
> > > +    case 3: base = "hole,zero"; break;
> > > +    }
> > > +    switch (type & 0xc) {
> > > +    case 0: depth = "unallocated"; break;
> >
> > Is this possible? qemu reports BDRV_BLOCK_DATA but not BDRV_BLOCK_ALLOCATED?
>
> No, qemu should never report a status of 0 (which in this code would
> produce the string "allocated,unallocated", although a v2 may change
> to print "<unexpected value>").
>
> Remember, BDRV_BLOCK_ALLOCATED is a bit of a misnomer - it has nothing
> to do with whether a cluster occupies allocated space, but rather
> whether the local image in the backing chain provides the contents of
> the cluster (rather than deferring to the backing chain).  The code in
> block/io.c guarantees that if a block device reports BDRV_BLOCK_DATA,
> then the block layer also reports BDRV_BLOCK_ALLOCATED (that is, any
> cluster that provides guest-visible data by necessity implies that the
> current layer of the backing chain is important).
>
> However, it DOES point out that "allocated" might not be the best name
> in libnbd; perhaps "data" or "normal" would be better for the NBD
> base:allocation status of 0.

Yes! it also aligns better with zero, and the output is similar to qemu-img map.
Hopefully the semantics of "data" in qemu-img map and libnbd is the same.