Re: [PATCH v3 1/1] qemu-img: Add --target-is-zero to convert

[Eric Blake]

On 2/7/20 8:41 AM, Max Reitz wrote:

> > > I could imagine a user creating a qcow2 image on some block device with
> > > preallocation where we cannot verify that the result will be zero.  But
> > > they want qemu not to zero the device, so they would specify
> > > --target-is-zero.
> >
> > If user create image, setting --target-is-zero is always valid. But if
> > we in
> > same operation create the image automatically, having --target-is-zero,
> > when
> > we know that what we are creating is not zero is misleading and should
> > fail..
>
> bdrv_has_zero_init() doesn’t return false only for images that we know
> are not zero.  It returns true for images where we know they are.  But
> if we don’t know, then it returns false also.

Huh?

bdrv_has_zero_init() currently returns 1 if a driver knows that creating 
an image results in that image reading as 0.  That means it can return 1 
even for non-zero images that were not just created.  Thus, that 
interface has both false positives (returning 1 for a non-zero image if 
the driver hard-codes it to 1) and false negatives (returning 0 for an 
image that happens to read as zero).  The false negatives are less 
important (if we don't know if the image is already zero, then zeroing 
it again is a waste of time but not semantically wrong) than the false 
positives (but as long as you don't rely on bdrv_has_zero_init() unless 
you also know the image was just created, you are safely avoiding the 
false positives).

And that's the whole point of my series to add a qcow2 persistent bit to 
track whether an image has known-zero contents: qemu-img should not be 
calling bdrv_has_zero_init(), since it is so finicky on what it means.

> > If we want to add a behavior to skip zeros unconditionally, we should
> > call new
> > option --skip-zeroes, to clearly specify what we want.
>
> It was my impression that this was exactly what --target-is-zero means
> and implies.

--target-is-zero turns into the behavior of 'skip a pre-zeroing pass'. 
If the destination is already zero, then copying zeroes from the source 
is a waste of time. If the destination is not already zero, then zeroes 
from the source are not copied, and the destination will not be 
identical to the source.  We then have a choice of whether 
--target-is-zero is merely a way to tell qemu something that it couldn't 
learn otherwise but still be as safe as possible (if we can quickly 
prove the target has non-zero data, the user lied about it being already 
zero, so fail the command, so add yet another option to bypass the 
safety check), or whether it really is synonymous with 'only copy the 
non-zero portions of the source, and if the destination was not all zero 
the copy is not faithful but I meant for it to be that way'.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org