If qemu-img convert sees that the target image isn't zero-initialised yet, it tries to do an efficient zero write for the whole image first to save the overhead of repeated explicit zero writes during the conversion. Obviously, this provides only an advantage if the pre-zeroing is actually efficient. Otherwise, we can end up writing zeroes slowly while zeroing out the whole image, and then overwrite the same blocks again with real data, potentially doubling the written data.
Additionally, commit 9776f0db changed NBD to advertise for all NBD devices that zero writes with unmap is supported for all NBD devices, no matter whether the storage of NBD server actually can do this or whether we would fall back to explicit zero writes. This series adds a new BDRV_REQ_NO_FALLBACK flag for writing zeroes, which makes the request return an error if it can't guarantee that we don't end up running a slow fallback path. For NBD, this means that we still support zero writes from guests, but qemu-img convert will not try to use it to zero out the whole image. This is potentially suboptimal if the server does actually support efficient zero writes. We'd need an NBD protocol extension to transfer this flag so we can re-enable the qemu-img convert feature for the NBD driver without regressing on storage that can't provide efficient zero writes. Kevin Wolf (6): block: Remove error messages in bdrv_make_zero() block: Add BDRV_REQ_NO_FALLBACK block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK include/block/block.h | 7 ++++++- include/block/raw-aio.h | 1 + block/blkdebug.c | 2 +- block/copy-on-read.c | 7 +++---- block/file-posix.c | 24 ++++++++++++++++-------- block/io.c | 16 +++++++++++----- block/mirror.c | 3 ++- block/raw-format.c | 2 +- qemu-img.c | 2 +- qemu-io-cmds.c | 13 +++++++++++-- 10 files changed, 53 insertions(+), 24 deletions(-) -- 2.20.1