qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Weil
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Fri, 18 Feb 2011 18:43:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11

Am 18.02.2011 10:57, schrieb Kevin Wolf:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf <address@hidden> writes:

Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the ideas in FVD and
consider them for qcow3.

Got an assumption there: that the one COW format we need must be qcow3,
i.e. an evolution of qcow2. Needs to be justified. If that discussion
has happened on the list already, I missed it. If not, it's overdue,
and then we better start it right away.

Right. I probably wasn't very clear about what I mean with qcow3 either,
so let me try to summarize my reasoning.


The first point is an assumption that you made, too: That we want to
have only one format. I hope it's easy to agree on this, duplication is
bad and every additional format creates new maintenance burden,
especially if we're taking it serious. Until now, there were exactly two
formats for which we managed to do this, raw and qcow2. raw is more or
less for free, so with the introduction of another format, we basically
double the supported block driver code overnight (while not doubling the
number of developers).

The consequence of having only one file format is that it must be able
to obsolete the existing ones, most notably qcow2. We can only neglect
qcow1 today because we can tell users to use qcow2. It supports
everything that qcow1 supports and more. We couldn't have done this if
qcow2 lacked features compared to qcow1.

So the one really essential requirement that I see is that we provide a
way forward for _all_ users by maintaining all of qcow2's features. This
is the only way of getting people to not stay with qcow2.


The support of several different file formats is one of the
strong points of QEMU, at least in my opinion.

Reducing this to offline conversion would be a bad idea because it costs
too much time and disk space for quick tests (for production environments,
this might be totally different).

Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done by Kevin.
Hopefully interfaces will stabilize, so changes will become less frequent.

A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!

Maybe adding a staging tree (like for the linux kernel) for experimental
drivers, devices, file formats, tcg targets and so on would make it easier
to add new code and reduce the need for QEMU forks. I'd appreciate such
or any other solution which allows this very much!

Regards,
Stefan




reply via email to

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