Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

[John Snow]

On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
> 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
> instability.

It's theoretical until I see performance testing numbers; do you have
any? How much faster does the pivot happen by avoiding making the qcow2
consistent on close?

I don't argue that it's faster to just simply not write data, but what's
not obvious is how much time it actually saves in practice and if that's
worth doing unintuitive and undocumented things like "the source file
loses bitmaps after a migration because it was faster."

> 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.
> 
> Den
>