From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdGkM-0000bj-CR for qemu-devel@nongnu.org; Fri, 17 May 2013 05:14:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdGkJ-0001DX-G1 for qemu-devel@nongnu.org; Fri, 17 May 2013 05:14:42 -0400 Received: from mail-bk0-x236.google.com ([2a00:1450:4008:c01::236]:59064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdGkJ-0001DA-6z for qemu-devel@nongnu.org; Fri, 17 May 2013 05:14:39 -0400 Received: by mail-bk0-f54.google.com with SMTP id it19so1621121bkc.27 for ; Fri, 17 May 2013 02:14:38 -0700 (PDT) Date: Fri, 17 May 2013 11:14:35 +0200 From: Stefan Hajnoczi Message-ID: <20130517091435.GA15001@stefanha-thinkpad.redhat.com> References: <1368628476-19622-1-git-send-email-stefanha@redhat.com> <519479B4.6080906@linux.vnet.ibm.com> <20130516074746.GF1597@stefanha-thinkpad.redhat.com> <5195D531.3000402@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5195D531.3000402@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, imain@redhat.com, Stefan Hajnoczi , Paolo Bonzini , dietmar@proxmox.com 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?