[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format |
Date: |
Mon, 06 Sep 2010 16:10:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6 |
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<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.
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
Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format, Anthony Liguori, 2010/09/06
Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format, Daniel P. Berrange, 2010/09/06
Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format, Anthony Liguori, 2010/09/06