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<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.
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
