From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39305 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OscPF-0005nY-AR for qemu-devel@nongnu.org; Mon, 06 Sep 2010 10:10:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OscPA-0001qB-Ta for qemu-devel@nongnu.org; Mon, 06 Sep 2010 10:10:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57513) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OscPA-0001px-Jd for qemu-devel@nongnu.org; Mon, 06 Sep 2010 10:10:40 -0400 Message-ID: <4C84F66C.8080607@redhat.com> Date: Mon, 06 Sep 2010 16:10:52 +0200 From: Kevin Wolf 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> <4C84E52D.1040800@codemonkey.ws> In-Reply-To: <4C84E52D.1040800@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Stefan Hajnoczi , qemu-devel@nongnu.org Am 06.09.2010 14:57, schrieb Anthony Liguori: > On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote: >> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf wrote: >> >>> 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. Due to its simpler on-disk layout, it is possible to safely >>>> perform metadata updates more efficiently. >>>> >>>> Installations, suspend-to-disk, and other allocation-heavy I/O workloads >>>> will see increased performance due to fewer I/Os and syncs. Workloads >>>> 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. It does not rely on the host >>>> filesystem holes feature, making it a good choice for sparse disk images >>>> that need to be transferred over channels where holes are not supported. >>>> >>>> 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. This eliminates the need for >>>> additional metadata to track copy-on-write clusters. >>>> >>>> Compression and encryption are not supported. They add complexity and >>>> 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: >>>> * Resizing the disk image. The capability has been designed in but the >>>> code has not been written yet. >>>> * Resetting the image after backing file commit completes. >>>> * Changing the backing filename. >>>> * Consistency check (fsck). This is simple due to the on-disk layout. >>>> >>>> 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? Yes. The motivation is >> to have an image format that performs well and is safe, with backing >> image support. Currently 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. I don't really buy that implementing compression/encryption wouldn't have been possible if it was the only problem. Of course, if you don't implement it, you can't use an on-disk format that supports them. > 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. Nothing is actually aligned. > This makes implementing things like O_DIRECT very challenging since you > basically have to handle bouncing any possible buffer. Since the L1 > table occurs immediately after the header, there's really no room to > play any kind of tricks to add features. That's a good point actually. I didn't remember that. Kevin