[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC V8 01/24] qcow2: Add journal specification.

From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC V8 01/24] qcow2: Add journal specification.
Date: Wed, 3 Jul 2013 10:08:53 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 02.07.2013 um 23:26 hat Benoît Canet geschrieben:
> > > 2. Byte-granularity means that read-modify-write is necessary to append
> > >    entries to the journal.  Therefore a failure could destroy previously
> > >    committed entries.
> > > 
> > >    Any ideas how existing journals handle this?
> > 
> > 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).
> > 
> > There's one "interesting" case: cache=writethrough. 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 io
> per metadata written to disk.

cache=writethrough already pretty much kills performance because it's
not only an I/O per metadata write, but also a flush.

The question is, do we have any option to avoid it?

> > 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 
> configurable.

This is more of a runtime option. We can store a default in the image,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]