|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format |
Date: | Fri, 10 Sep 2010 16:19:15 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2 |
On 09/10/2010 04:10 PM, Stefan Hajnoczi wrote:
On Fri, Sep 10, 2010 at 1:47 PM, Avi Kivity<address@hidden> wrote:On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: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. 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. I think the reason we haven't seen them before is because the effort and the baggage of doing them is too great. Sure, we maintain existing formats but I don't see active development pushing virtualized storage happening.The same could be said about much of qemu. It is an old code base that wasn't designed for virtualization. Yet we maintain it and develop it because compatibility is king.For compatibility? I figured the amount of effort to implement all the device emulation and BIOS was not deemed worth starting from scratch.
You're right. Even if someone did suggest to implement it because it sucks, we'd cry foul because of the risk to compatibility.
My chief complaint against vbus was compatibility, and while qed isn't in exactly the same position (we're a lot more flexible on the host than on the guest), it does put a burden on users.
I don't see how qed has any inherent performance advantage, it is essentially the same as qcow2 minus refcounting, which is easily batched. It's a lot easier to work with, both because it's a new code base and because it's simpler, but both of these will erode in time.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Prev in Thread] | Current Thread | [Next in Thread] |