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

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