On Thu, Jun 10, 2021 at 4:06 PM Eric Blake <ebl...@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.