On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote: > * John Snow (js...@redhat.com) wrote: >> >> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote: >>> * John Snow (js...@redhat.com) 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 / dgilb...@redhat.com / 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. 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
