Am 21.02.2011 16:16, schrieb Anthony Liguori: > On 02/21/2011 08:10 AM, Kevin Wolf wrote: >> Am 21.02.2011 14:44, schrieb Stefan Hajnoczi: >> >>> On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf<kw...@redhat.com> wrote: >>> >>>> In fact, the only area where qcow2 in performs really bad in 0.14 is >>>> cache=writethrough (which unfortunately is the default...). With >>>> cache=none it's easy to find scenarios where it provides higher >>>> throughput than QED. >>>> >>> Yeah, I'm tempted to implement parallel allocating writes now so I can >>> pick on qcow2 in all benchmarks again ;). >>> >> Heh. ;-) >> >> In the end it just shows that the differences are mainly in the >> implementation, not in the format. >> >> >>>> Anyway, there's really only one crucial difference between QED and >>>> qcow2, which is that qcow2 ensures that metadata is consistent on disk >>>> at any time whereas QED relies on a dirty flag and rebuilds metadata >>>> after a crash (basically requiring an fsck). The obvious solution if you >>>> want to have this in qcow2, is adding a dirty flag there as well. >>>> >>>> Likewise, I think FVD might provide some ideas that we can integrate as >>>> well, I just don't see a justification to include it as a separate format. >>>> >>> You think that QED and FVD can be integrated into a QCOW2-based >>> format. I agree it's possible and has some value. It isn't pretty >>> and I would prefer to work on a clean new format because that, too, >>> has value. >>> >>> In any case, the next step is to get down to specifics. Here is the >>> page with the current QCOW3 roadmap: >>> >>> http://wiki.qemu.org/Qcow3_Roadmap >>> >>> Please raise concrete requirements or features so they can be >>> discussed and captured. >>> >>> For example, journalling is an alternative to the dirty bit approach. >>> If you feel that journalling is the best technique to address >>> consistent updates, then make your case outside the context of today's >>> qcow2, QED, and FVD implementations (although benchmark data will rely >>> on current implementations). Explain how the technique would fit into >>> QCOW3 and what format changes need to be made. >>> >> I think journalling is an interesting option, but I'm not sure if we >> should target it for 0.15. As you know, there's already more than enough >> stuff to do until then, with coroutines etc. The dirty flag thing would >> be way easier to implement. We can always add a journal as a compatible >> feature in 0.16. >> >> To be honest, I'm not even sure any more that the dirty flag is that >> important. Originally we have been talking about cache=none and it >> definitely makes a big difference there because we save flushes. >> However, we're talking about cache=writethrough now and you flush on any >> write. It might be more important to make things parallel for writethrough. >> > > One thing I wonder about is whether we really need to have cache=X and > wce=X. I never really minded the fact that cache=none advertised wce=on > because we behaved effectively as if wce=on. But now that qcow2 > triggers on wce=on, I'm a bit concerned that we're introducing a subtle > degradation that most people won't realize. > > Ignoring some of the problems with O_DIRECT, semantically, I think > there's a strong use-case for cache=none, wce=off.
Fully agree, there's no real reason for having three writeback modes, but only one writethrough mode. It should be completely symmetrical. I think Christoph has mentioned several times that he has some patches for this. What's the status of them, Christoph? Kevin