[Top][All Lists]

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

Re: [Qemu-block] [PATCH for-4.0? 0/6] block: Fix slow pre-zeroing in qem

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH for-4.0? 0/6] block: Fix slow pre-zeroing in qemu-img convert
Date: Fri, 22 Mar 2019 09:32:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/22/19 9:21 AM, Eric Blake wrote:
> 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 <address@hidden>
> and I'll be cross-posting another mail soon with the desired NBD
> protocol extension.

I also meant to add - since the performance slowdown is so noticeable,
and we are still at -rc0, I think this series is reasonable as 4.0
material as a bug fix (performance bugs rank lower than correctness
bugs, but they are still bugs)

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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