>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).
As long as it's outside the region of the source image I think you can leave it alone. Similar to deleting a file on a disk also doesn't zero out the sectors that were used to store that file before. >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. Going that path would certainly break the way Openstack Ironic project uses qemu-img via the ironic-python-agent to image baremetal servers. And I can imagine there are other cases out there using qemu-img to write out disk images to blockdevices. Fred