[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,
though.
Kevin