From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:54004)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SXqN9-0000yw-Jm
	for qemu-devel@nongnu.org; Fri, 25 May 2012 04:59:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SXqN3-0006mu-F5
	for qemu-devel@nongnu.org; Fri, 25 May 2012 04:59:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:64003)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1SXqN3-0006mh-7C
	for qemu-devel@nongnu.org; Fri, 25 May 2012 04:59:41 -0400
Message-ID: <4FBF49EA.2000502@redhat.com>
Date: Fri, 25 May 2012 10:59:22 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <4FB6821A.1080902@redhat.com> <4FBE3A89.8020702@redhat.com>
	<4FBE3EFE.4020402@zerto.com> <4FBE435C.2050206@redhat.com>
	<4FBE547C.7020505@redhat.com>
In-Reply-To: <4FBE547C.7020505@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2,
 including support for replication]
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: dlaor@redhat.com
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>, Ori Mamluk <omamluk@zerto.com>, Eric Blake <eblake@redhat.com>

Il 24/05/2012 17:32, Dor Laor ha scritto:
> I didn't understand whether the persistent dirty bitmap needs to be
> flushed. This bitmap actually control the persistent known state of the
> destination image. Since w/ mirroring we always have the source in full
> state condition, we can choose to lazy update the destination w/ a risk
> of loosing some content from the last flush (of the destination only side).

Flushing the dirty bitmap after writing to the target can indeed be
tuned for the application.  However, it is not optional to msync the
bitmap when flushing the source.  If the source has a power loss, it has
to know what to retransmit.

> This way one can pick the frequency of flushing the persistent bits map
> (and the respective target IO writes).  Continuous replication can chose
> a timely based fashion, such as every 5 seconds.

But then the target is not able to restore a consistent state (which is
a state where the dirty bitmap is all-zeros).

The scheme above is roughly what DRBD does.  But in any case,
optimizations need to be worked out with a model checker, it's too delicate.

Paolo