From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uejvz-000613-V2 for qemu-devel@nongnu.org; Tue, 21 May 2013 06:36:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uejvv-0005wt-CS for qemu-devel@nongnu.org; Tue, 21 May 2013 06:36:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uejvv-0005wn-3Y for qemu-devel@nongnu.org; Tue, 21 May 2013 06:36:43 -0400 Message-ID: <519B4E31.6040503@redhat.com> Date: Tue, 21 May 2013 12:36:33 +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> <519603C1.5060104@redhat.com> <5199CF7F.3060507@redhat.com> <20130521073159.GA30951@stefanha-thinkpad.muc.redhat.com> <519B309E.6020201@redhat.com> <20130521103413.GA19747@stefanha-thinkpad.muc.redhat.com> In-Reply-To: <20130521103413.GA19747@stefanha-thinkpad.muc.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 , Stefan Hajnoczi , qemu-devel , Dietmar Maurer , imain@redhat.com, Wenchao Xia Il 21/05/2013 12:34, Stefan Hajnoczi ha scritto: > On Tue, May 21, 2013 at 10:30:22AM +0200, Paolo Bonzini wrote: >> Il 21/05/2013 09:31, Stefan Hajnoczi ha scritto: >>> On Mon, May 20, 2013 at 09:23:43AM +0200, Paolo Bonzini wrote: >>>> Il 20/05/2013 08:24, Stefan Hajnoczi ha scritto: >>>>>>> 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! >>>> >>>> But data modifications can go undetected until the guest flush returns, >>>> can't they? >>> >>> You are thinking about it from the guest perspective - if a flush has >>> not completed yet then there is no guarantee that the write has reached >>> disk. >>> >>> But from a host perspective the dirty bitmap should be conservative so >>> that the backup application can always restore a bit-for-bit identical >>> copy of the disk image. It would be weird if writes can sneak in >>> unnoticed. >> >> True, but that would happen only in case the host crashes. Even for a >> QEMU crash the changes would be safe, I think. They would be written >> back when the persistent dirty bitmap's mmap() area is unmapped, during >> process exit. > > I'd err on the side of caution, mark the persistent dirty bitmap while > QEMU is running. Discard the file if there was a power failure. Agreed. Though this is something that management must do manually, isn't it? QEMU cannot distinguish a SIGKILL from a power failure, while management can afford treating SIGKILL as a power failure. > It really depends what the dirty bitmap users are doing. It could be > okay to have a tiny chance of missing a modification but it might not. Paolo