From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdEdX-0007kk-Cb for qemu-devel@nongnu.org; Fri, 17 May 2013 02:59:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdEdW-0001tE-Be for qemu-devel@nongnu.org; Fri, 17 May 2013 02:59:31 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:40883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdEdT-0001sL-6V for qemu-devel@nongnu.org; Fri, 17 May 2013 02:59:30 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 17 May 2013 16:50:46 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id BDB313578050 for ; Fri, 17 May 2013 16:59:14 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4H6j23223068720 for ; Fri, 17 May 2013 16:45:03 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4H6xDT3027972 for ; Fri, 17 May 2013 16:59:13 +1000 Message-ID: <5195D531.3000402@linux.vnet.ibm.com> Date: Fri, 17 May 2013 14:58:57 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1368628476-19622-1-git-send-email-stefanha@redhat.com> <519479B4.6080906@linux.vnet.ibm.com> <20130516074746.GF1597@stefanha-thinkpad.redhat.com> In-Reply-To: <20130516074746.GF1597@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Stefan Hajnoczi Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, imain@redhat.com, Paolo Bonzini , dietmar@proxmox.com 于 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. > Backup applications need to support the full backup case anyway for > their first run. Therefore we can keep a best-effort dirty bitmap which > is persisted only when the guest is terminated cleanly. If the QEMU > process crashes then the on-disk dirty bitmap will be invalid and the > backup application needs to do a full backup next time. > > The advantage of this approach is that we don't need to fdatasync(2) > before every guest write operation. > >> Compared with >> current solution, I think it is doing COW at qemu device level: >> >> qemu device >> | >> general block layer >> | >> virtual format layer >> | >> ----------------------- >> | | >> qcow2 vmdk.... >> >> This will make things complicated when more works comes, a better >> place for block COW, is under general block layer. Maybe later we >> can adjust block for it. > > 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, and leaves an abstract API for it. Some other operation such as commit, stream, could be also hide under block. qemu general testcase other user | | | -------------------------------------------------- | core block abstract layer(COW, zero R/W, image dup/backup) | --------------------- | | qemu's implement 3'rd party | | ------------- -------------- | | | | qcow2 vmdk lvm2 Enterprise storage integration It is not directly related to this serial, but I feel some effort should be paid when time allows, before things become complicated. > The drive-backup operation doesn't really affect the source > BlockDriverState, it just needs to intercept writes. Therefore it seems > cleaner for the code to live separately (plus we reuse the code for the > block job loop which copies out data while the guest is running). > Otherwise we would squash all of the blockjob code into block.c and it > would be an even bigger mess than it is today :-). > -- Best Regards Wenchao Xia