qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 15:48:30 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7

Am 10.09.2010 14:35, schrieb Stefan Hajnoczi:
> On Fri, Sep 10, 2010 at 1:12 PM, Kevin Wolf <address@hidden> wrote:
>> Am 10.09.2010 13:43, schrieb Stefan Hajnoczi:
>>>>>>> By creating two code paths within qcow2.
>>>>>>
>>>>>> You're creating two code paths for users.
>>>>>
>>>>> No, I'm creating a single path: QED.
>>>>>
>>>>> There are already two code paths: raw and qcow2.  qcow2 has had such a bad
>>>>> history that for a lot of users, it's not even a choice.
>>>>
>>>> qcow2 exists, people use it, and by the time qed is offered on distros 
>>>> (even
>>>> more on enterprise distros), there will be a lot more qcow2 images.  Not
>>>> everyone runs qemu.git HEAD.
>>>>
>>>> What will you tell those people?  Upgrade your image?  They may still want
>>>> to share it with older installations.  What if they use features not 
>>>> present
>>>> in qed?  Bad luck?
>>>>
>>>> qcow2 is going to live forever no matter what we do.
>>>
>>> It should be possible to do (live) upgrades for supported images.
>>
>> That still leaves those qcow2 images that use features not supported by
>> qed. Just a few features missing in qed are internal snapshots, qcow2 on
>> block devices, compression, encryption. So qed can't be a complete
>> replacement for qcow2 (and that was the whole point of doing qed). If
>> anything, it can exist besides qcow2.
> 
> qcow2 is a feature-driven format.  It sacrifices some of the core
> qualities of an image format in exchange for advanced features.  I
> like to use qcow2 myself for desktop virtualization.
> 
> qed applies the 80/20 rule to disk image formats.  Let's perfect the
> basics for most users at a fraction of the {development,performance}
> cost.

So let's translate this into an answer to the question we're discussing
here: Yes, Avi is right, qcow2 is going to live forever.

> Then, with a clean base that takes on board the lessons of existing
> formats it is much easier to innovate.  Look at the image streaming,
> defragmentation, and trim ideas that are playing out right now.  

All of these are possible with qcow2 as well or even better than with
qed. For example trim feels like a really hacky thing in qed whereas
freeing a cluster is something just natural in qcow2.

Kevin



reply via email to

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