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
