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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Sep 6, 2010 at 11:27 AM, Kevin Wolf <kwolf@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 <aliguori@us.ibm.com>
>> Signed-off-by: Stefan Hajnoczi <stefanha@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.  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