From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45773 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsbKu-0003JB-FF for qemu-devel@nongnu.org; Mon, 06 Sep 2010 09:02:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OsbKs-0007Yu-WC for qemu-devel@nongnu.org; Mon, 06 Sep 2010 09:02:12 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:46302) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OsbKs-0007Yn-RD for qemu-devel@nongnu.org; Mon, 06 Sep 2010 09:02:10 -0400 Received: by vws19 with SMTP id 19so3399042vws.4 for ; Mon, 06 Sep 2010 06:02:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C84E52D.1040800@codemonkey.ws> References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84C213.4060005@redhat.com> <4C84E52D.1040800@codemonkey.ws> Date: Mon, 6 Sep 2010 14:02:09 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On Mon, Sep 6, 2010 at 1:57 PM, Anthony Liguori wro= te: > On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote: >> >> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf =A0wrote: >> >>> >>> Am 06.09.2010 12:04, schrieb Stefan Hajnoczi: >>> >>>> >>>> QEMU Enhanced Disk format is a disk image format that forgoes features >>>> found in qcow2 in favor of better levels of performance and data >>>> integrity. =A0Due to its simpler on-disk layout, it is possible to saf= ely >>>> perform metadata updates more efficiently. >>>> >>>> Installations, suspend-to-disk, and other allocation-heavy I/O workloa= ds >>>> will see increased performance due to fewer I/Os and syncs. =A0Workloa= ds >>>> that do not cause new clusters to be allocated will perform similar to >>>> raw images due to in-memory metadata caching. >>>> >>>> The format supports sparse disk images. =A0It does not rely on the hos= t >>>> filesystem holes feature, making it a good choice for sparse disk imag= es >>>> that need to be transferred over channels where holes are not supporte= d. >>>> >>>> Backing files are supported so only deltas against a base image can be >>>> stored. >>>> >>>> The file format is extensible so that additional features can be added >>>> later with graceful compatibility handling. >>>> >>>> Internal snapshots are not supported. =A0This eliminates the need for >>>> additional metadata to track copy-on-write clusters. >>>> >>>> Compression and encryption are not supported. =A0They add complexity a= nd >>>> can be implemented at other layers in the stack (i.e. inside the guest >>>> or on the host). >>>> >>>> The format is currently functional with the following features missing= : >>>> =A0* Resizing the disk image. =A0The capability has been designed in b= ut the >>>> =A0 =A0code has not been written yet. >>>> =A0* Resetting the image after backing file commit completes. >>>> =A0* Changing the backing filename. >>>> =A0* Consistency check (fsck). =A0This is simple due to the on-disk la= yout. >>>> >>>> Signed-off-by: Anthony Liguori >>>> Signed-off-by: Stefan Hajnoczi >>>> >>> >>> 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. 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? >>> >> >> Is this a subset of existing on-disk formats? =A0Yes. =A0The motivation = is >> to have an image format that performs well and is safe, with backing >> image support. =A0Currently no image format in QEMU meets these >> requirements. >> >> Perhaps it is appropriate to use an existing on-disk format. > > If you implement a subset of functionality for an existing on-disk format= , I > think you damage user's expectations. > > If we claim to support qcow images, then given any old qcow image I have > laying around for 5 years ago, I should be able to run it without qemu > throwing an error. > > There's some really ugly stuff in qcow. =A0Nothing is actually aligned. = =A0This > makes implementing things like O_DIRECT very challenging since you basica= lly > have to handle bouncing any possible buffer. =A0Since the L1 table occurs > immediately after the header, there's really no room to play any kind of > tricks to add features. These are the details that are baggage. Ultimately it may be hard to deal with them without just bumping the qcow version number and thereby having a new format anyway. Stefan