From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44394 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Osb4m-0005yT-5Q for qemu-devel@nongnu.org; Mon, 06 Sep 2010 08:45:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Osb4l-0005FD-4K for qemu-devel@nongnu.org; Mon, 06 Sep 2010 08:45:32 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:51227) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Osb4l-0005F5-1u for qemu-devel@nongnu.org; Mon, 06 Sep 2010 08:45:31 -0400 Received: by gxk26 with SMTP id 26so1903770gxk.4 for ; Mon, 06 Sep 2010 05:45:30 -0700 (PDT) Message-ID: <4C84E26B.4030207@codemonkey.ws> Date: Mon, 06 Sep 2010 07:45:31 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84C213.4060005@redhat.com> In-Reply-To: <4C84C213.4060005@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org 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 > >