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

[Anthony Liguori]

On 09/06/2010 09:10 AM, Kevin Wolf wrote:
> > 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.
>    

The trouble with compression is that you don't have fixed size clusters 
any more.  In order to support writes, you either have to write 
uncompressed data to the EOF leaking the compressed version or write 
compressed data and attempt to use a free list to avoid leaking 
clusters.  Since cluster size isn't fixed, the free list is of variable 
size which means you'd have to do something sophisticated like a buddy 
algorithm to allocate from the free list.

It's just not worth it since there's no easy way to do it correctly.

Encryption is straight forward.

Lack of features is a killer though.  The only thing you could really do 
is the same type of trickery we did with qcow2 where we detect whether 
there's room between the header and the L1.  Of course, there's nothing 
in qcow that really says if the L1 doesn't start at sizeof(old_header) 
then you have new_header so this is not technically backwards compatible.

But even assuming it is, the new features introduced in new_header are 
undiscoverable to older version of QEMU.  So if you do something that 
makes the image unreadable to older QEMUs (like adding a new encryption 
algorithm), instead of getting a nice error, you get silent corruption.  
qcow has had more than the QEMU implementation too so we're not the only 
ones that have been creating qcow images so we can't just rely on our 
historic behavior.

IMHO, this alone justifies a new format.

Regards,

Anthony Liguori

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