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

[Kevin Wolf]

Am 20.02.2011 23:13, schrieb Aurelien Jarno:
> On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
>> 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.
> 
> I agree that the best would be to have a single format, and it's
> probably a goal to have. That said, what is most important to my view is
> having one or two formats which together have _all_ the features (and 
> here I consider speed as a feature) of the existing qcow2 format. QED or
> FVD have been designed with the "virtualization in a datacenter" in mind,
> and are very good for this use. OTOH they don't support compression or 
> snapshotting, that are quite useful for demo, debugging, testing, or
> even for occasionally running a Windows VM, in other words in situations
> where the speed is not the priority.
> 
> If we can't find a tradeoff for that, we should go for two instead of 
> one image format.

I agree. Though that's purely theoretical because there no reason why we
shouldn't find a way to get both. ;-)

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.

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.

In my opinion, an additional flag certainly doesn't justify maintaining
an additional format instead of extending the existing one.

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.

Kevin