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

[Vladimir Sementsov-Ogievskiy]

11.03.2019 20:48, Eric Blake wrote:
> On 3/11/19 12:36 PM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>> 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.
> 
> And I'm still not convinced that adding bitmap flushing will add a
> benchmarkable delay to operation. Although debugging may not be needed
> in a production environment, having it after a failure can be a lifesaver.

What is the real debugging case, when we need this information? Keeping in mind,
that it may still be incorrect due to different error paths? (resize failed on
some point before flush, or resize successed but flush failed)

> 
> Looking at this from another point of view: if this series goes in now
> (with its use of limited bitmap flushing on resize in order to make
> coding bitmap resize easier, rather than global bitmap flushing after
> every bitmap add/delete), then the only time that flushing to disk
> happens is during resize (which is currently flat-out forbidden), so it
> will not penalize existing use cases. And we still have rc1/rc2 to fix
> any bugs if we can come up with some other way to get resize to work
> without flushing (or even revert things if it proves to be too
> invasive). But as a feature addition, if this series does not go in now,
> then bitmap resize is stuck waiting for 4.2, regardless of what we can
> figure out during rc1/rc2.
> 
>>
>> Bitmaps are stored in qcow2_inactivate() which is true place for flushing 
>> caches.
>>
> 
> There doesn't have to be just one place for flushing caches.  In terms
> of IOPs, how much overhead does a flush cost in relation to everything
> else?

Assume we have 16tb disk. Bitmap with default granularity will take 30mb.
Assume that we have several such bitmaps (for example, several disabled and
one active, remember differential backups and related staff). So, it will
be several hundreds of megabytes.

   And how infrequent are bitmap resize, add, and delete events?
> Optimizing to the bare minimum of flushes just because it adds minimal
> overhead may be premature optimization if that overhead is in the noise
> anyway.
> 


-- 
Best regards,
Vladimir