From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Un0hZ-0005Ro-En for qemu-devel@nongnu.org; Thu, 13 Jun 2013 02:08:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Un0hY-0002RB-7g for qemu-devel@nongnu.org; Thu, 13 Jun 2013 02:08:05 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:41776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Un0hX-0002QH-EU for qemu-devel@nongnu.org; Thu, 13 Jun 2013 02:08:04 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Jun 2013 11:31:26 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id B06133940043 for ; Thu, 13 Jun 2013 11:37:56 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5D67oDJ9109646 for ; Thu, 13 Jun 2013 11:37:51 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5D67rMm010050 for ; Thu, 13 Jun 2013 16:07:54 +1000 Message-ID: <51B961A4.1060608@linux.vnet.ibm.com> Date: Thu, 13 Jun 2013 14:07:32 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1369917299-5725-1-git-send-email-stefanha@redhat.com> <1369917299-5725-4-git-send-email-stefanha@redhat.com> <20130606035618.GA24375@localhost.nay.redhat.com> <20130606080513.GA13466@stefanha-thinkpad.redhat.com> <20130606085649.GA15648@localhost.nay.redhat.com> <20130607071812.GA16953@stefanha-thinkpad.redhat.com> <51B960BA.4050801@linux.vnet.ibm.com> In-Reply-To: <51B960BA.4050801@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v5 03/11] block: add basic backup support to block driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, imain@redhat.com, Paolo Bonzini , dietmar@proxmox.com 于 2013-6-13 14:03, Wenchao Xia 写道: > 于 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. > I mean that "get writable snapshot (possibility to open backing file writable and write to it safely) as a by-product." in this series, is not very valuable. -- Best Regards Wenchao Xia