Re: [Qemu-devel] [PATCH] block/dirty-bitmap: Documentation and Comment fixups

[Vladimir Sementsov-Ogievskiy]

02.02.2019 4:01, John Snow wrote:
> 
> 
> On 1/31/19 3:29 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>> About @frozen and @locked, we can also note that they can't be exported 
>> through NBD.
>> We can summarize, that @frozen and @locked means that user can't use them in 
>> any
>> command, and the only option is to list them. However even info->count 
>> information
>> should not be considered as something meaningful, as bitmaps are under some 
>> operations.
>> And we can also use same paragraph for @frozen and @locked, as a first step 
>> to @frozen
>> deprecation.
> 
> There's a subtle difference in the two, namely that:
> 
> (1) Frozen may or may not record new writes, but they don't "show up"
> until after the operation is over, because it's using a second bitmap as
> a temporary buffer.
> 
> (2) Locked may or may not record new writes *immediately*.
> 
> Regardless, I'm realizing that for both Frozen and Locked bitmaps we
> want to allow users to know if the bitmap is recording or not. (And
> possibly if there is a temporary write cache or not, but maybe it's not
> important.)
> 
> Maybe we want two new fields on query:
> 
> Recording/Enabled: [True | False]
> Busy/Locked:       [True | False] (or "Locked)
> 
> which will then deprecate the status field. This doesn't manage to
> communicate the write cache nuance, but maybe we don't need to.

Agree.

> 
> (It also doesn't help elucidate whether or not the successor is
> active/disabled, but even for migration once the guest has started, the
> successors are always enabled, right?)
> 
> Thoughts?
> 

Hmmm, it's all really questionable.

What we want to exporot about bitmaps?

A. For not-locked, not-frozen:

It's obvious enough: we want to say that bitmap is not locked and available for
any operation, and all information we have, is it disabled or not, dirty count, 
etc.

So we have two possible states here:
(not-locked, disabled)
(not-locked, enabled)

B. For locked of frozen:

Firsty, dirty-count seems not useful and not reliable.

Disabled/enabled.. what it means for locked bitmaps?

1. for frozen (used only in backups), enabled means, that writes are tracked in 
context
of this bitmaps, and after operation finish information about dirtiness will be 
available
somehow. But details about reclaim/abdicate are related to the operation, not 
to the bitmap
status.

2. for locked bitmap, again, enabled means that it tracks dirtiness.

...

So, yes, [recording, not-recording] x [busy, not-busy] works. And we may 
document
recording for busy case like "guest writes are tracked in context of the 
bitmap, but
availability of tracked information as well as bitmap status after holding 
operation
depends on the operation itself"


-- 
Best regards,
Vladimir