Re: Reporting absent extents in qcow2 image

[Nir Soffer]

On Tue, Jun 15, 2021 at 2:23 PM Vladimir Sementsov-Ogievskiy
<vsementsov@virtuozzo.com> wrote:
>
> 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"?

Unallocated area in an image, exposing the backing file.

The term case from NBD_STATE_HOLE, which was reported in the past
based on BDRV_BLOCK_ALLOCATED. Before
commit 0da9856851dcca09222a1467e16ddd05dc66e460
nbd/server.c was using:

        flags = (ret & BDRV_BLOCK_ALLOCATED ? 0 : NBD_STATE_HOLE) |
                (ret & BDRV_BLOCK_ZERO      ? NBD_STATE_ZERO : 0);

Since this is oVirt public API, we cannot change the semantics at this point.

When we reconstruct a qcow2 via nbd server, we skip the area so on the
target image
this area is not allocated.

> 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
>