From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHqRt-0000NW-NP for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:27:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHqRm-0007bu-1E for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:27:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHqRl-0007bl-OP for qemu-devel@nongnu.org; Fri, 06 Sep 2013 03:27:13 -0400 Date: Fri, 6 Sep 2013 09:27:05 +0200 From: Kevin Wolf Message-ID: <20130906072705.GC2588@dhcp-200-207.str.redhat.com> 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> <20130905152626.GB5095@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130905152626.GB5095@irqsave.net> 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: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: jcody@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , mreitz@redhat.com Am 05.09.2013 um 17:26 hat Beno=EEt Canet geschrieben: > 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 t= hem? > > > >=20 > > > > This is a question for Beno=EEt, who made this requirement. I ask= ed him > > > > the same a while ago and apparently his explanation made some sen= se 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 blo= ck get > > > created and deleted in a cyclic way it can generate cyclic insertio= ns/deletions > > > journal entries. > > > The journal could easilly be filled if this pathological corner cas= e happen. > > > When it happen the dedup code repack the journal by writting only t= he 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 pres= ent in the > > > journal hence the multiple journal requirement. > > >=20 > > > The deduplication also need two journals because when the first one= is frozen it > > > take some time to write the hash table to disk and anyway new entri= es must be > > > stored somewhere at the same time. The code cannot block. > > >=20 > > > > It might have something to do with the fact that deduplication us= es the > > > > journal more as a kind of cache for hash values that can be dropp= ed 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 f= or > > dedupe? Maybe your original proposal was fine for dedupe and we just > > misinterpreted it because we thought this needs to be a safe journal. >=20 > Kevin what do you think of this ? > I could strip down the dedupe journal code to specialize it. If you think it turns out easier than using the journalling infrastructure that we're going to implement anyway, then why not. Kevin