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.
(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?
