13.04.2018 18:05, Nikolay Shirokovskiy wrote:

On 13.04.2018 14:41, Vladimir Sementsov-Ogievskiy wrote:
13.04.2018 11:51, Nikolay Shirokovskiy wrote:
On 13.04.2018 03:04, John Snow wrote:
On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
I propose, not to say that bitmap represents a checkpoint. It is simpler
to say (and it reflects the reality) that bitmap is a difference between
two consecutive checkpoints. And we can say, that active state is some
kind of a checkpoint, current point in time.

So, we have checkpoints (5* is an active state) which are points in time:

1 2 3 4 5*

Oh -- the most recent checkpoint there doesn't belong to a ***specific
time*** yet. It's a floating checkpoint -- it always represents the most
current version. It's not really a checkpoint at all.

1, 2, 3, and 4 however are associated with a specific timestamp though.

And bitmaps, first three are disabled, last is enabled:

"1->2", "2->3", "3->4", "4->5*"

OK; so 1->2, 2->3 and 3->4 define deltas between two ***defined***
points in time.

4->5* however is only anchored by one specific point in time, and is
floating just like the most recent checkpoint is floating.

So, remove first checkpoint: just remove bitmap "A->B".
I assume you mean "1->2" here.

And... yes, I agree -- if you don't care about your very first
checkpoint anymore, you can just delete the first bitmap, too.

Remove any other checkpoint N: create new bitmap "(N-1)->(N+1)" =
merge("(N-1)->N", "N->(N+1)"), drop bitmaps "(N-1)->N" and "N->(N+1)".
err, okay, so let's say we want to drop checkpoint 3:

create: "2->4"
merge: "2->3", "3->4" [and presumably store in "2->4"]
drop: 2->3, 3->4

OK, that makes more sense to me. In essence;

(1) We could consider this 2->3 absorbing 3->4, or
(2) 3->4 absorbing 2->3

and in either case it's the same, really.

If the latter was active, the new one becomes active. And we cant remove
5* checkpoint, as it is an active state, not an actual checkpoint.
OK, crystal.


I prefer not talking of active checkpoint. It is a kind of controversial.
Better just keep in mind that last bitmap is active one. So for checkpoints 1 2 
3 4
we have bitmaps:

1 1->2 2->3 3->4

Note the first bitmap name. When it was created name 2 was unknown so we'd 
have this name for the first bitmap.
so here, 1->2 is a difference between checkpoints 2 and 3? I think it's 
unnatural.. Ofcource, when we create new active bitmap, we don't know the name of 
next checkpoint, but, why not rename it when we create next checkpoint?


1. have no checkpoints and bitmaps
2. create new checkpoint 1, and bitmap 1->?
3. create new checkpoint 2 and bitmap 2->?, disable bitmap 1->? and rename it to 
and so on.

this reflects the essence of things
Makes sense and I don't see any issue from implementation POV. I would only use > only 
or >> (or whatever times >)
instead of ->. This makes possible to restrict names to prohibit > only. - is 
typical for UUIDs.

in this case, I think just > is ok. Less symbols - less electricity/paper/time overhead)

And more. This do not look like a hack (may be a bit=)

Why not to call the bitmap, representing difference between snapshots A and B: A>B?

Best regards,

libvir-list mailing list

Reply via email to