Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command

[Stefan Hajnoczi]

On Tue, May 21, 2013 at 11:25:01AM +0800, Wenchao Xia wrote:
> 于 2013-5-17 17:14, Stefan Hajnoczi 写道:
> >On Fri, May 17, 2013 at 02:58:57PM +0800, Wenchao Xia wrote:
> >>于 2013-5-16 15:47, Stefan Hajnoczi 写道:
> >>>On Thu, May 16, 2013 at 02:16:20PM +0800, Wenchao Xia wrote:
> >>>>   After checking the code, I found it possible to add delta data backup
> >>>>support also, If an additional dirty bitmap was added.
> >>>
> >>>I've been thinking about this.  Incremental backups need to know which
> >>>blocks have changed, but keeping a persistent dirty bitmap is expensive
> >>>and unnecessary.
> >>>
> >>   Yes, it would be likely another block layer, so hope not do that.
> >
> >Not at all, persistent dirty bitmaps need to be part of the block layer
> >since they need to support any image type - qcow2, Gluster, raw LVM,
> >etc.
> >
> >>>I don't consider block jobs to be "qemu device" layer.  It sounds like
> >>>you think the code should be in bdrv_co_do_writev()?
> >>>
> >>   I feel a trend of becoming fragility from different solutions,
> >>and COW is a key feature that block layer provide, so I wonder if it
> >>can be adjusted under block layer later
> >
> >The generic block layer includes more than just block.c.  It also
> >includes block jobs and the qcow2 metadata cache that Dong Xu has
> >extracted recently, for example.  Therefore you need to be more specific
> >about "what" and "why".
> >
> >This copy-on-write backup approach is available as a block job which
> >runs on top of any BlockDriverState.  What concrete change are you
> >proposing?
> >
>   Since hard to hide it BlockDriverState now, suggest add some
> document in qemu about the three snapshot types: qcow2 internal,
> backing chain, drive-backup, which are all qemu software based snapshot
> implemention, then user can know the difference with it eaiser.
> 
>   In long term, I hope to form a library expose those in a unified
> format, perhaps it calls qmp_transaction internally, and make it
> easier to be offloaded if possible, so hope a abstract-driver structure.

Okay, just keep in mind they have different behavior.  That means these
snapshot types solve different problems and may be inappropriate for
some use cases.

Stefan