Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver

[Stefan Hajnoczi]

On Thu, Jun 06, 2013 at 04:56:49PM +0800, Fam Zheng wrote:
> On Thu, 06/06 10:05, Stefan Hajnoczi wrote:
> > On Thu, Jun 06, 2013 at 11:56:18AM +0800, Fam Zheng wrote:
> > > On Thu, 05/30 14:34, Stefan Hajnoczi wrote:
> > > > +
> > > > +static int coroutine_fn backup_before_write_notify(
> > > > +        NotifierWithReturn *notifier,
> > > > +        void *opaque)
> > > > +{
> > > > +    BdrvTrackedRequest *req = opaque;
> > > > +
> > > > +    return backup_do_cow(req->bs, req->sector_num, req->nb_sectors, 
> > > > NULL);
> > > > +}
> > > 
> > > I'm wondering if we can see the logic here with a backing hd
> > > relationship?  req->bs is a backing file of job->target, but guest is
> > > going to write to it, so we need to COW down the data to job->target
> > > before overwritting (i.e.  cluster is not allocated in child).
> > >
> > > I think if we do this in block layer, there's not much necessity for a
> > > before-write notifier here (although it may be useful for other cases):
> > > 
> > >     in bdrv_write:
> > >     for child in req->bs->open_children
> > >         if not child->is_allocated(req->sectors)
> > >             do COW to child
> > > 
> > > The advantage of this is that we won't need to start block-backup job in
> > > sync mode "none" to do point-in-time snapshot (image fleecing), and we
> > > get writable snapshot (possibility to open backing file writable and
> > > write to it safely) as a by-product.
> > > 
> > > But we will need to keep track of parent<->child of block states, and we
> > > still need to take care of overlapping writing between block job and
> > > guest request.
> > 
> > There's one catch here: bs->target may not support backing files, it can
> > be a raw file, for example.  We'll only use backing files for
> > point-in-time snapshots but other use cases might not.  raw doesn't
> > really implement is_allocated(), so the whole concept would have to
> > change a little:
> 
> Another use case may be parent modification. Suppose we have
> 
>                     ,--- child1.qcow2
>     parent.qcow2  <
>                     `--- child2.qcow2
> 
> We can use parent.qcow2 as block device in QEMU without breaking
> child1.qcow2 or child2.qcow2 by telling QEMU who its children are:
> 
>   $QEMU -drive file=parent.qcow2,children=child1.qcow2:child2.qcow2
> 
> Then we open the three images and setup parent_bs->open_children, the
> children are protected from being corrupted.
> 
> > 
> > bs->open_children becomes independent of backing files - any
> > BlockDriverState can be added to this list.  ->is_allocated() basically
> > becomes the bitmap that we keep in the block job.
> 
> Yes. But it is possible to keep a bitmap for raw (and those don't
> implement is_allocated()) in block layer too, or in overlay: could
> add-cow by Dongxu Wang help here?

Yes absolutely.

Stefan