From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeJWc-0005ca-Uo for qemu-devel@nongnu.org; Mon, 20 May 2013 02:24:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UeJWY-0000VC-D1 for qemu-devel@nongnu.org; Mon, 20 May 2013 02:24:50 -0400 Received: from mail-qc0-x233.google.com ([2607:f8b0:400d:c01::233]:52936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeJWY-0000V8-8X for qemu-devel@nongnu.org; Mon, 20 May 2013 02:24:46 -0400 Received: by mail-qc0-f179.google.com with SMTP id e1so1250140qcx.24 for ; Sun, 19 May 2013 23:24:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <519603C1.5060104@redhat.com> References: <1368628476-19622-1-git-send-email-stefanha@redhat.com> <519479B4.6080906@linux.vnet.ibm.com> <20130516074746.GF1597@stefanha-thinkpad.redhat.com> <519603C1.5060104@redhat.com> Date: Mon, 20 May 2013 08:24:45 +0200 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 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: Paolo Bonzini Cc: Kevin Wolf , Fam Zheng , qemu-devel , Wenchao Xia , imain@redhat.com, Stefan Hajnoczi , Dietmar Maurer On Fri, May 17, 2013 at 12:17 PM, Paolo Bonzini wrote: > 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? No, you need to set the dirty bit before issuing the write on the host. Otherwise the image data may be modified without setting the appropriate dirty bit. That would allow data modifications to go undetected! Stefan