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.