Re: [RFC v2] external (pull) backup API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--js

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 better
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?

So,

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 1->2
and so on.

this reflects the essence of things


Checkpoint 4 can not be used without checkpoint 5 by design to it is not a problem
that 3->4 is active.

Nikolay


--
Best regards,
Vladimir

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux