Re: [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps

[Vladimir Sementsov-Ogievskiy]

11.03.2019 19:18, Eric Blake wrote:
> On 3/5/19 5:43 PM, John Snow wrote:
>> This series aims to enable block resizes when persistent bitmaps are
>> in use. The basic approach here is to recognize that we now load all
>> persistent bitmaps in memory, and so we can rely on in-memory resizes
>> and then flush the changed metadata back to disk.
>>
>> One part that is potentially now quite strange is that bitmap resizes
>> may happen twice: once during the qcow2 resize event only if persistent
>> bitmaps are found, and then again as part of the generic resize callback
>> event whether or not we have any persistent bitmaps.
>>
>> The second round is required if we are not using qcow2 or we have only
>> transient bitmaps. The first round is required as we wish to flush the
>> bitmaps back to disk atomically with the qcow2 resize to avoid violating
>> our invariants for the bitmap metadata which is checked in many places.
>>
>> This is harmless; hbitmap_truncate will recognize the second round as
>> a no-op.
> 
> FWIW - I have not yet reviewed this series closely, but I think it would
> be wise to get this initial cut in before softfreeze (we can make
> further tweaks to fix bugs in assumptions during rc1 and rc2, but it's a
> lot harder to add the series at all if it misses softfreeze).
> 

I still not convinced that we need bitmap flushing. I think (and Den supports
me) that it's a bad idea. It makes things more difficult without a reason,
except improving debugging with --force-share which should never be used in
production.

Bitmaps are stored in qcow2_inactivate() which is true place for flushing 
caches.

-- 
Best regards,
Vladimir