Am 24.11.2017 um 16:01 hat Vladimir Sementsov-Ogievskiy geschrieben:
> John, Kevin, do we reach a consensus? Can we go on with this?
I don't know the details of this, so I can't really offer a strong
opinion. I gave a high-level perspective of what we're doing in other
places and that's all I was planning to contribute at the moment. So I'm
deferring this to John.
If you guys can't find a decision or are uncertain about the approach,
please let me know and I can try to find the time to actually get into
the details and provide some more in-depth feedback.
Kevin
> 20.11.2017 19:00, Denis V. Lunev wrote:
> > On 11/17/2017 06:10 AM, John Snow wrote:
> > > On 11/16/2017 03:17 AM, Vladimir Sementsov-Ogievskiy wrote:
> > > > 16.11.2017 00:20, John Snow wrote:
> > > > > On 11/13/2017 11:20 AM, Vladimir Sementsov-Ogievskiy wrote:
> > > > > > Hi all.
> > > > > >
> > > > > > There are three qmp commands, needed to implement external backup
> > > > > > API.
> > > > > >
> > > > > > Using these three commands, client may do all needed bitmap
> > > > > > management by
> > > > > > hand:
> > > > > >
> > > > > > on backup start we need to do a transaction:
> > > > > > {disable old bitmap, create new bitmap}
> > > > > >
> > > > > > on backup success:
> > > > > > drop old bitmap
> > > > > >
> > > > > > on backup fail:
> > > > > > enable old bitmap
> > > > > > merge new bitmap to old bitmap
> > > > > > drop new bitmap
> > > > > >
> > > > > Can you give me an example of how you expect these commands to be
> > > > > used,
> > > > > and why they're required?
> > > > >
> > > > > I'm a little weary about how error-prone these commands might be and
> > > > > the
> > > > > potential for incorrect usage seems... high. Why do we require them?
> > > > It is needed for incremental backup. It looks like bad idea to export
> > > > abdicate/reclaim functionality, it is simpler
> > > > and clearer to allow user to merge/enable/disable bitmaps by hand.
> > > >
> > > > usage is like this:
> > > >
> > > > 1. we have dirty bitmap bitmap0 for incremental backup.
> > > >
> > > > 2. prepare image fleecing (create temporary image with backing=our_disk)
> > > > 3. in qmp transaction:
> > > > - disable bitmap0
> > > > - create bitmap1
> > > > - start image fleecing (backup sync=none our_disk -> temp_disk)
> > > This could probably just be its own command, though:
> > >
> > > block-job-fleece node=foobar bitmap=bitmap0 etc=etera etc=etera
> > >
> > > Could handle forking the bitmap. I'm not sure what the arguments would
> > > look like, but we could name the NBD export here, too. (Assuming the
> > > server is already started and we just need to create the share.)
> > >
> > > Then, we can basically do what mirror does:
> > >
> > > (1) Cancel
> > > (2) Complete
> > >
> > > Cancel would instruct QEMU to keep the bitmap changes (i.e. roll back),
> > > and Complete would instruct QEMU to discard the changes.
> > >
> > > This way we don't need to expose commands like split or merge that will
> > > almost always be dangerous to use over QMP.
> > >
> > > In fact, a fleecing job would be really convenient even without a
> > > bitmap, because it'd still be nice to have a convenience command for it.
> > > Using an existing infrastructure and understood paradigm is just a bonus.
> > >
> > actually this is a very good question about safety/simplicity...
> >
> > We actually have spent a bit of time on design and have not
> > come to a good solution. Yes, technically for now we can put
> > all into fleecing command and rely on its semantics. Though
> > I am not convinced with that approach. We can think that this
> > can be reused on snapshot operations (may be, may be not).
> > Also technically there are other cases.
> >
> > This is actually a matter that QEMU should provide low level
> > API while management software should make decisions.
> > Providing merge etc operations is done using exactly that
> > approach. We can also consider this in a similar way we have
> > recently fixed "revert to snapshot" operation. Management
> > can make and should make a decision.
> >
> > Den
> >
>
>
> --
> Best regards,
> Vladimir
>
