[libvirt] [RFC v2] external (pull) backup API

[Vladimir Sementsov-Ogievskiy]

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.
>>>>
>>>> --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
> 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,
Vladimir