[Top][All Lists]

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

Re: [Qemu-block] [PATCH v2 7/7] mirror: improve performance of mirroring

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v2 7/7] mirror: improve performance of mirroring of empty disk
Date: Tue, 12 Jul 2016 09:45:41 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 07/11/2016 11:57 PM, Fam Zheng wrote:
> On Mon, 07/11 15:53, John Snow wrote:
>> On 07/07/2016 05:35 AM, Denis V. Lunev wrote:
>>> We should not take into account zero blocks for delay calculations.
>>> They are not read and thus IO throttling is not required. In the
>>> other case VM migration with 16 Tb QCOW2 disk with 4 Gb of data takes
>>> days.

>> What I wonder is if we shouldn't be deterministically reading how much
>> data we are actually shuffling over the pipe and using that for
>> ratelimiting instead of in a higher abstraction layer "guessing" how
>> much data we're going to be sending.
> It's a good question, I wonder if it is possible that block layer can even use
> a fallback of write write_zeroes even write_zeroes_ok is true?

Indeed, if you do an unaligned write, then write_zeroes will fall back
to normal write for at least the head and tail, based on whether the
driver returns -ENOTSUP.

Right now, we are rather loose on what the block layer returns on
successful writes - we guarantee that we don't do short writes (you
either have everything written, or you get a negative result), but
sometimes we return 0 and sometimes we return the length that was
written.  Maybe we could formalize it into the length of data sent over
the wire (return 0 if it was optimized, non-zero if data was sent)? But
that may require a rather large audit of code to implement.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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