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

[Kevin Wolf]

Am 18.02.2011 10:12, schrieb Markus Armbruster:
> Kevin Wolf <address@hidden> writes:
> 
>> Am 15.02.2011 20:45, schrieb Chunqiang Tang:
>>>> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
>>>> As you requested, I set up a wiki page for FVD at 
>>> http://wiki.qemu.org/Features/FVD
>>>> . It includes a summary of FVD, a detailed specification of FVD, and a 
>>>> comparison of the design and performance of FVD and QED. 
>>>
>>>> See the figure at http://wiki.qemu.org/Features/FVD/Compare . This 
>>> figure 
>>>> shows that the file creation throughput of NetApp's PostMark benchmark 
>>> under 
>>>> FVD is 74.9% to 215% higher than that under QED.
>>>
>>> Hi Anthony,
>>>
>>> Please let me know if more information is needed. I would appreciate your 
>>> feedback and advice on the best way to proceed with FVD. 
>>
>> 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.


Of course, you could invent another format that implements the same
features, but I think just carefully extending qcow2 has some real
advantages.

The first is that conversion of existing images would be really easy.
Basically increment the version number in the header file and you're
done. Structures would be compatible. If you compare it to file systems,
I rarely ever change the file system on a non-empty partition. Even if I
wanted, it's usually just too painful. Except when I was able to use
"tune2fs -j" to make ext3 out of ext2, that was really easy. We can
provide the same for qcow2 to qcow3 conversion, but not with a
completely new format.

Also, while obsoleting a file format means that we need not put much
effort in its maintenance, we still need to keep the code around for
reading old images. With an extension of qcow2, it would be the same
code that is used for both versions.

Third, qcow2 already exists, is used in practice and we have put quite
some effort into QA. At least initially confidence would be higher than
in a completely new, yet untested format. Remember that with qcow3 I'm
not talking about rewriting everything, it's a careful evolution, mostly
with optional additions here and there.

Kevin