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: Wenchao Xia
Subject: Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver
Date: Thu, 13 Jun 2013 14:03:38 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

于 2013-6-7 15:18, 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

  One advantage of external backup, or backing up chain, is that it
holds 'Delta' data only and is small enough. If it is changed toward a
'full' data writable snapshot, it become bigger. With backup chain
qemu-img can restore/clone a writable and usable one, So I don't
think adding that in qemu emulator helps much, and it will make things
more complicit.... user won't care who is doing the job, qemu or
qemu-img.

--
Best Regards

Wenchao Xia




reply via email to

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