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

[Kevin Wolf <kwolf@redhat.com>]

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

Or we could just refuse to convert if source and target aren't the same
size. Then you would have to use a raw filter driver to select a part
from the target image with the offset/size options. But this would break
backwards compatibility, and its use is not very intuitive either.

Unfortunately, this is just the kind of problems that raw images give
you. :-/

Kevin