Re: Reporting absent extents in qcow2 image

[Vladimir Sementsov-Ogievskiy]

15.06.2021 01:29, Nir Soffer wrote:
> oVirt started to use now qemu:allocation-depth meta context.
> In the past, we use base:allocation and reported NBD_STATE_HOLE
> as a hole, and this broke in qemu 6.0.0.
>
> Now we have NBD_STATE_HOLE from base:allocation, and flags == 0
> from qemu:allocation-depth.
>
> We map flags == 0 to  EXTENT_BACKING (1<<3), and merge with the
> flags from base:allocation.
>
> EXTENT_BACKING is internal bit not exposed to users. It matches the
> backing=true proposed for "qemu-img map", and the BACKING_FILE
> bit used qemu-img convert.
>
> We report a hole if:

The main question: what do you mean by "hole"?

As far as I understand allocation-depth reports 0 IFF

 - we have a chain of qcow2 image, and the bottom is qcow2, not raw
AND
 - in all these images the cluster is UNALLOCATED, i.e. points to backing

>      flags & NBD_STATE_HOLE and flags & EXTENT_BACKING
>
> But is it really needed to consider NBD_STATE_HOLE?
>
> Looking in nbd/server.c, when depth is reported as 0, we always
> get NBD_STATE_HOLE:

seems yes.

>          flags = (ret & BDRV_BLOCK_DATA ? 0 : NBD_STATE_HOLE) |
>                  (ret & BDRV_BLOCK_ZERO ? NBD_STATE_ZERO : 0);
>
> Looks like we should use only qemu:allocation-depth to report holes,
> and ignore NBD_STATE_HOLE. Maybe later we can use NBD_STATE_HOLE
> to report sparseness (e.g. "allocated": True).
>
> What do you think?
>
> Nir


--
Best regards,
Vladimir