Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format

[Anthony Liguori]

On 09/06/2010 07:40 AM, Stefan Hajnoczi wrote:
> On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf<address@hidden>  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<address@hidden>
> > > Signed-off-by: Stefan Hajnoczi<address@hidden>
> > >        
> > 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.

Regards,

Anthony Liguori

>    I
> actually considered in-place migration (compatibility) with qcow2 to
> make life easier for users and avoid a new format.  However, there is
> baggage to doing this and the focus should be on building a solid
> image format instead of fitting into a legacy format that qemu-img
> convert can take care of.
>
> Stefan
>
>