From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu83s-00042Q-9o for qemu-devel@nongnu.org; Tue, 02 Jul 2013 17:24:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu83q-0000v3-QE for qemu-devel@nongnu.org; Tue, 02 Jul 2013 17:24:32 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:38757 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu83q-0000uu-Hi for qemu-devel@nongnu.org; Tue, 02 Jul 2013 17:24:30 -0400 Date: Tue, 2 Jul 2013 23:26:15 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130702212615.GC4985@irqsave.net> References: <1371738392-9594-1-git-send-email-benoit@irqsave.net> <1371738392-9594-2-git-send-email-benoit@irqsave.net> <20130702144224.GF9870@stefanha-thinkpad.redhat.com> <20130702145446.GG3031@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130702145446.GG3031@dhcp-200-207.str.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC V8 01/24] qcow2: Add journal specification. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi > > 2. Byte-granularity means that read-modify-write is necessary to appe= nd > > entries to the journal. Therefore a failure could destroy previou= sly > > committed entries. > >=20 > > Any ideas how existing journals handle this? >=20 > You commit only whole blocks. So in this case we can consider a block > only committed as soon as a TYPE_END entry has been written (and after > that we won't touch it any more until the journalled changes have been > flushed to disk). >=20 > There's one "interesting" case: cache=3Dwritethrough. I'm not entirely > sure yet what to do with it, but it's slow anyway, so using one block > per entry and therefore flushing the journal very often might actually > be not totally unreasonable. This sure would finish to kill the performance because this would be an i= o per metadata written to disk. >=20 > Another thing I'm not sure about is whether a fixed 4k block is good or > if we should leave it configurable. I don't think making it an option > would hurt (not necessarily modifyable with qemu-img, but as a field > in the file format). I agree. I also think about make the number of block to be flushed at once configu= rable. Beno=EEt