From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:57327)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Uehxx-0001Wj-SM
	for qemu-devel@nongnu.org; Tue, 21 May 2013 04:30:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Uehxt-000311-8j
	for qemu-devel@nongnu.org; Tue, 21 May 2013 04:30:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:24601)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Uehxt-00030j-28
	for qemu-devel@nongnu.org; Tue, 21 May 2013 04:30:37 -0400
Message-ID: <519B309E.6020201@redhat.com>
Date: Tue, 21 May 2013 10:30:22 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
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>
	<CAJSP0QXNm4Yn0RTkOKOBusMK=HrLbambsoMuJ6W-otXZ=tcJBg@mail.gmail.com>
	<5199CF7F.3060507@redhat.com>
	<20130521073159.GA30951@stefanha-thinkpad.muc.redhat.com>
In-Reply-To: <20130521073159.GA30951@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Dietmar Maurer <dietmar@proxmox.com>, imain@redhat.com, Wenchao Xia <xiawenc@linux.vnet.ibm.com>

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.

Paolo