Am 22.03.2019 um 14:21 hat Kevin Wolf geschrieben: > 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.
Applied to the block branch. Kevin
