qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver
Date: Thu, 6 Jun 2013 10:05:13 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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:

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.

In the end I'm not sure there is much advantage since we need
backup_do_cow() and the overlapping request code anyway for the block
job.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]