From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57916)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1VH9UZ-0006zM-Vo
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 05:35:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1VH9UT-0000WD-Tc
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 05:35:15 -0400
Received: from nodalink.pck.nerim.net ([62.212.105.220]:59849
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1VH9UT-0000Vu-Ks
	for qemu-devel@nongnu.org; Wed, 04 Sep 2013 05:35:09 -0400
Date: Wed, 4 Sep 2013 11:37:11 +0200
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130904093710.GB5054@irqsave.net>
References: <1378215952-7151-1-git-send-email-kwolf@redhat.com>
	<20130904080352.GA8031@stefanha-thinkpad.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130904080352.GA8031@stefanha-thinkpad.redhat.com>
Subject: Re: [Qemu-devel] [RFC] qcow2 journalling draft
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>, benoit.canet@irqsave.net, famz@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com

> > +They consist of transactions, which in turn contain operations that
> > +are effectively executed atomically. A qcow2 image can have a main image
> > +journal that deals with cluster management operations, and additional specific
> > +journals can be used by other features like data deduplication.
> 
> I'm not sure if multiple journals will work in practice.  Doesn't this
> re-introduce the need to order update steps and flush between them?

The flush and data has reached stable storage requirement of the deduplication
journal are very weak.
The deduplication code maintains an incompatible "dedup dirty" flag and flush
the journal on exit then clear the flag.
If the flag is set at startup all deduplication metadata and journal content are
dropped and it does not harm the image file in any way.
The code just starts over.