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.
--js
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
