[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
signature.asc
Description: OpenPGP digital signature