[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmap

From: Denis V. Lunev
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic
Date: Wed, 1 Aug 2018 21:42:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
> * John Snow (address@hidden) wrote:
>> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
>>> * John Snow (address@hidden) wrote:
>>> <snip>
>>>> I'd rather do something like this:
>>>> - Always flush bitmaps to disk on inactivate.
>>> Does that increase the time taken by the inactivate measurably?
>>> If it's small relative to everything else that's fine; it's just I
>>> always worry a little since I think this happens after we've stopped the
>>> CPU on the source, so is part of the 'downtime'.
>>> Dave
>>> --
>>> Dr. David Alan Gilbert / address@hidden / Manchester, UK
>> I'm worried that if we don't, we're leaving behind unusable, partially
>> complete files behind us. That's a bad design and we shouldn't push for
>> it just because it's theoretically faster.
> Oh I don't care about theoretical speed; but if it's actually unusably
> slow in practice then it needs fixing.
> Dave

This is not "theoretical" speed. This is real practical speed and
EACH IO operation can be performed unpredictably slow and thus with
IO operations in mind you can not even calculate or predict downtime,
which should be done according to the migration protocol.

That is why we have very specifically (for the purpose) improved
migration protocol to migrate CBT via postcopy method, which
does not influence downtime.

That is why we strictly opposes any CBT writing operation in migration
code. It should also be noted, that CBT can be calculated for all discs,
including raw but could be written for QCOW2 only. With external CBT storage
for such discs the situation during migration would become even worse.


reply via email to

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