From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbQ8-00053h-6W for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:24:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHbQ2-00075W-7B for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:24:32 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:60512 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbQ1-00075P-SW for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:24:26 -0400 Date: Thu, 5 Sep 2013 17:26:26 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130905152626.GB5095@irqsave.net> References: <1378215952-7151-1-git-send-email-kwolf@redhat.com> <20130904080352.GA8031@stefanha-thinkpad.redhat.com> <20130904093950.GB3562@dhcp-200-207.str.redhat.com> <20130904095523.GC5054@irqsave.net> <20130905092440.GB12293@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130905092440.GB12293@stefanha-thinkpad.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] qcow2 journalling draft List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Kevin Wolf , famz@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com Le Thursday 05 Sep 2013 =E0 11:24:40 (+0200), Stefan Hajnoczi a =E9crit : > On Wed, Sep 04, 2013 at 11:55:23AM +0200, Beno=EEt Canet wrote: > > > > 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 the= m? > > >=20 > > > This is a question for Beno=EEt, who made this requirement. I asked= him > > > the same a while ago and apparently his explanation made some sense= to > > > me, or I would have remembered that I don't want it. ;-) > >=20 > > The reason behind the multiple journal requirement is that if a block= get > > created and deleted in a cyclic way it can generate cyclic insertions= /deletions > > journal entries. > > The journal could easilly be filled if this pathological corner case = happen. > > When it happen the dedup code repack the journal by writting only the= non > > redundant information into a new journal and then use the new one. > > It would not be easy to do so if non dedup journal entries are presen= t in the > > journal hence the multiple journal requirement. > >=20 > > The deduplication also need two journals because when the first one i= s frozen it > > take some time to write the hash table to disk and anyway new entries= must be > > stored somewhere at the same time. The code cannot block. > >=20 > > > It might have something to do with the fact that deduplication uses= the > > > journal more as a kind of cache for hash values that can be dropped= and > > > rebuilt after a crash. > >=20 > > For dedupe the journal is more a "resume after exit" tool. >=20 > I'm not sure anymore if dedupe needs the same kind of "journal" as a > metadata journal for qcow2. >=20 > Since you have a dirty flag to discard the "journal" on crash, the > journal is not used for data integrity. >=20 > That makes me wonder if the metadata journal is the right structure for > dedupe? Maybe your original proposal was fine for dedupe and we just > misinterpreted it because we thought this needs to be a safe journal. Kevin what do you think of this ? I could strip down the dedupe journal code to specialize it. Best regards Beno=EEt