Re: [Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf <kwolf@redhat.com>]

Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
> On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf <kwolf@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.

Maybe not writing out refcounts is something we should measure before we
start implementing anything. (It's easy to disable all writes for a
benchmark, even if the image will be broken afterwards)

> I think this is the level we need to discuss at rather than qcow2 vs QED vs FVD.

Definitely more productive, yes.

Kevin