qemu-devel
[Top][All Lists]
Advanced

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

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


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





reply via email to

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