[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] block: Fix slow pre-zeroing in qemu-img con

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/6] block: Fix slow pre-zeroing in qemu-img convert
Date: Mon, 25 Mar 2019 13:04:05 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]