[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] The two image formats called qcow



Keir Fraser schrieb:
> On 26/3/08 13:54, "Kevin Wolf" <kwolf@xxxxxxx> wrote:
> 
>> ioemu: Fix L1 table endianess of qcow images created by tapdisk
>>
>> The qemu/ioemu implementation of the qcow format uses a big endian L1
>> table. tapdisk omits the necessary conversion, so qcow images have the
>> wrong endianess and cannot be read by correct implementations of qcow.
>>
>> This patch detects broken tapdisk images and converts their L1 tables to
>> big endian when the image file is opened in ioemu for the first time.
>> The fixed image has a new flag EXTHDR_L1_BIG_ENDIAN set in the extended
>> header.
>>
>> Note that a converted image cannot be opened by tapdisk again.
> 
> Can we really tack an 'extended header' into a public format like qcow?

I didn't introduce this, it was already there in tapdisk. I don't see a
problem with it as the start of the L1 table is referenced in the normal
qcow header. qemu-img sets this to something like 0x48 which is
immediately after the header, tapdisk uses 0x1000 and gains some unused
space for things like the extended header. This is compatible with the
qcow implementation of qemu/ioemu.

On the other hand, I could simply strip that extended header (i.e.
overwrite the magic with 0x0) after having fixed the image. Then it
wouldn't be detected as broken on the next start as well.

Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.