|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format |
Date: | Mon, 06 Sep 2010 07:45:31 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 09/06/2010 05:27 AM, Kevin Wolf wrote:
Okay, so before I actually look at the patch longer than a couple of seconds let me just ask the obvious question... Before inventing yet another image format, you certainly have checked the existing ones.
Obviously, yes. Here are the issues:cow.c: it's cow of an otherwise sparse file. An important reason for implementing a format is the ability to copy (or scp) an image without special tools.
qcow2.c: the refcount, cow cluster, and compression make an implementation seeking integrity and performance challenging.
vmdk.c: we feel it's important for qemu to have a block format with a gpl friendly specification that we have a say in
vhd/vpc.c: same as vmdk with the addition that the OSP is known to not be gpl friendly
vdi.c: uses a bitmap instead of a two level table. An advantage of a two level table is that it allows image resize without much fuss.
qcow.c: it lacks extensibility and compression means that there's no guarantee that blocks are a fixed size. This makes it very difficult to implement a high performance block format without having two separate code paths.
Except for not implementing compression and encryption this looks a lot like qcow1 to me. I see that you even retained the two-level cluster tables. So if we ignore the implementation for a moment and just compare the formats, what's the crucial difference between qcow1 and qed that I'm missing? And if it's not qcow1, why not improving our support for another existing format like VHD?
Block formats are easy to get wrong. QED is an existence proof that given the right constraints, we can build a full asynchronous, high performance image format with proper data integrity.
You could get to QED by incrementally improving qcow but you'd have to break the format to make it extensible and disable support for compression. But at that point, why not just make a new format since you're breaking compatibility.
You would have to fully rewrite the code so what's the point of keeping the format?
Regards, Anthony Liguori
Kevin
[Prev in Thread] | Current Thread | [Next in Thread] |