On 07/10/2017 05:17 AM, Vladimir Sementsov-Ogievskiy wrote:
Can we document this somehow?
In this terminology, what happens with frozen bitmap (which in fact is
like "active" for the user) on successful backup finish? It turns into a
difference between current-state and what-was-backed-up? It is not very
transparent.. May be bitmap part, related to the backup is substituted
from the bitmap?
// it's hard for me to believe that 'frozen' doesn't mean 'can not
move', but if it is already established idea then ok.
Admittedly a mistake on my part, mixing up implementation detail and
exposed interface. It's not necessarily an established idea...
To the end-user, a bitmap that is "frozen" is still indeed recording new
writes from a certain point of view, because once the backup completes,
the bitmap (secretly: the promoted successor) will contain writes that
occurred during that frozen period of time. How could this happen unless
our "frozen" bitmap was recording writes?
Oops, that's not very frozen at all, is it.
That's an unfortunate bit of design that I didn't take into account when
I named the "Frozen" property and exposed it via the JSON API. I was
only thinking about it from the implementation point of view, like you
are -- the bitmap _is_ well and truly frozen: it cannot be modified and
does not record any writes. (Only the successor does, as you know.)
So as it stands we have a discrepancy in the code between internal and
external usage over what exactly "frozen" implies. It's a poor name.
I should have named the QAPI-facing portion of it "locked" or
"protected" or something that helped imply that it could continue to
change, but it was off-limits.