On 09/06/2010 05:45 AM, Anthony Liguori wrote:
>>
>> Before inventing yet another image format, you certainly have checked
>> the existing ones.
>
> Obviously, yes.
>
> Here are the issues:
>
> cow.c: it's cow of an otherwise sparse file. An important reason for
> implementing a format is the ability to copy (or scp) an image without
> special tools.
>
> qcow2.c: the refcount, cow cluster, and compression make an
> implementation seeking integrity and performance challenging.
>
> vmdk.c: we feel it's important for qemu to have a block format with a
> gpl friendly specification that we have a say in
>
> vhd/vpc.c: same as vmdk with the addition that the OSP is known to not
> be gpl friendly
>
> vdi.c: uses a bitmap instead of a two level table. An advantage of a
> two level table is that it allows image resize without much fuss.
>
> qcow.c: it lacks extensibility and compression means that there's no
> guarantee that blocks are a fixed size. This makes it very difficult to
> implement a high performance block format without having two separate
> code paths.
>
Okay... how about, say, Linux LVM2 format?
-hpa
