Re: [Qemu-devel] [Qemu-block] Request for clarification on qemu-img convert behavior zeroing target host_device

[Daniel P . Berrangé]

On Fri, Dec 14, 2018 at 01:26:59PM +0100, Kevin Wolf wrote:
> Am 14.12.2018 um 11:59 hat De Backer, Fred (Nokia - BE/Antwerp) geschrieben:
> > >>> Indeed, performance traces are important for issues like this.
> > >>See strace of both FC27 and FC29 attached
> > 
> > >Looks like you traced only the main thread. All the I/O is done in other 
> > >threads.
> > >These flags would be useful:
> > >
> > >    strace -o log -f -T -tt
> > 
> > New straces attached with mentioned flags.  Both truncated due to file
> > size at what I believe to be the same position in the "write-phase".
> > FC29 has the "zeroing-phase" in front.
> 
> So this is indeed using BLKZEROOUT, which has a slow fallback in the
> kernel (slow means ~12 seconds for each 2 GB chunk).
> 
> We need to avoid calling BLKZEROOUT in the context of pre-zeroing the
> image for qemu-img convert.
> 
> Of course, we should also think about the other problem you mentioned,
> related to copying a smaller image to a larger block device. Does this
> require zeroing the parts after the image or should we leave them alone?
> 
> I'd tend to say that since you're passing the whole block device as a
> target to 'qemu-img convert', and the whole block device will be visible
> to a guest run with the same block device configuration, we should
> indeed zero out the whole device. But then we would declare the F27
> behaviour buggy and this case would stay slow (it would become slightly
> faster because we avoid the double writes, but we wouldn't save the
> writes to the unused space).

I think this behaviour needs to be configurable.

Exposing old data from the block device to the guest is indeed a
security flaw, however, qemu-img can't ever know if there is old
data there or not. Assuming the worst case is a sensible default,
but is too pessimistic to be hardcoded.

If the mgmt application has taken care to ensure the volume was
already zeroed out, there should be a way for it to tell qemu-img
not to do zero'ing again.

Zero'ing of block devices is very expensive and so you really
don't want to it to be done in the hot startup path. I recall
that to deal with this, Nova (or was it Cinder) put zero'ing
of block devices into the guest cleanup path in the background.
That way the expensive zero'ing operation is done at a place
there it won't impact any user visible operations. It just
delays the time until the block device can be re-used for a
new guest.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|