On 3/22/19 8:21 AM, Kevin Wolf wrote: > 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.
I haven't reviewed closely yet, but the summary is sane, so: Acked-by: Eric Blake <ebl...@redhat.com> and I'll be cross-posting another mail soon with the desired NBD protocol extension. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
