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
