Re: [PATCH 00/17] Improve qcow2 all-zero detection

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

31.01.2020 20:44, Eric Blake wrote:
> Based-on: <20200124103458.1525982-2-david.edmondson@oracle.com>
> ([PATCH v2 1/2] qemu-img: Add --target-is-zero to convert)
> 
> I'm working on adding an NBD extension that reports whether an image
> is already all zero when the client first connects.  I initially
> thought I could write the NBD code to just call bdrv_has_zero_init(),
> but that turned out to be a bad assumption that instead resulted in
> this patch series.  The NBD patch will come later (and cross-posted to
> the NBD protocol, libnbd, nbdkit, and qemu, as it will affect all four
> repositories).
> 
> I do have an RFC question on patch 13 - as implemented here, I set a
> qcow2 bit if the image has all clusters known zero and no backing
> image.  But it may be more useful to instead report whether all
> clusters _allocated in this layer_ are zero, at which point the
> overall image is all-zero only if the backing file also has that
> property (or even make it two bits).  The tweaks to subsequent patches
> based on what we think makes the most useful semantics shouldn't be
> hard.
> 
> [repo.or.cz appears to be down as I type this; I'll post a link to a
> repository later when it comes back up]
> 

I have several ideas around it.

1. For generic block layer.
Did you consider as alternative to BDRV_ZEO_OPEN, to export the
information through normal block_status? So, if we have the
information, that disk is all-zero, we can always add _ZERO
flag to block-status result. And in generic bdrv_is_all_zeroes(),
we can just call block_status(0, disk_size), which will return
ZERO and n=disk_size if driver supports all-zero feature and is
all-zero now.
I think block-status is a native way for such information, and I
think that we anyway want to come to support of 64bit block-status
for qcow2 and nbd.

2. For NBD
Again, possible alternative is BLOCK_STATUS, but we need 64bit
commands for it. I plan to send a proposal anyway. Still, nothing
bad in two possible path of receiving all-zero information.
And even with your NBD extension, we can export this information
through block-status [1.]

3. For qcow2
Hmm. Here, as I understand, than main case is freshly created qcow2,
which is fully-unallocated. To understand that it is empty, we
need only to check all L1 entries. And for empty L1 table it is fast.
So we don't need any qcow2 format improvement to check it.




-- 
Best regards,
Vladimir