On Mon, Sep 6, 2010 at 1:57 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote: >> >> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf<kw...@redhat.com> 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<aligu...@us.ibm.com> >>>> Signed-off-by: Stefan Hajnoczi<stefa...@linux.vnet.ibm.com> >>>> >>> >>> 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. > > 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.
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
