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

[Stefan Hajnoczi]

On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf <address@hidden> 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 ;).

> 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 this is the level we need to discuss at rather than qcow2 vs QED vs FVD.

Stefan