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
