From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdHjR-0005dq-Ow for qemu-devel@nongnu.org; Fri, 17 May 2013 06:17:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdHjQ-0007lf-CA for qemu-devel@nongnu.org; Fri, 17 May 2013 06:17:49 -0400 Received: from mail-gg0-x232.google.com ([2607:f8b0:4002:c02::232]:64426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdHjQ-0007lZ-7W for qemu-devel@nongnu.org; Fri, 17 May 2013 06:17:48 -0400 Received: by mail-gg0-f178.google.com with SMTP id a5so470087ggn.23 for ; Fri, 17 May 2013 03:17:47 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <519603C1.5060104@redhat.com> Date: Fri, 17 May 2013 12:17:37 +0200 From: Paolo Bonzini 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=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, dietmar@proxmox.com, imain@redhat.com, Wenchao Xia Il 16/05/2013 09:47, Stefan Hajnoczi ha scritto: > 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. > > 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. You only need to fdatasync() before every guest flush, no? Paolo >> 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()? > > 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 :-). > >