Re: [Qemu-devel] qcow2x

[Kevin Wolf <kwolf@redhat.com>]

Am 03.08.2011 15:39, schrieb Frediano Ziglio:
> 2011/8/2 Kevin Wolf <kwolf@redhat.com>:
>> Am 02.08.2011 17:29, schrieb Frediano Ziglio:
>>>>> - L2 allocation can be done with relative data (this is not easy to do
>>>>> with current code)
>>>>
>>>> What do you mean by that?
>>>>
>>>
>>> Let's take an example. By allocation I mean give a position to
>>> data/l2/refcount_table. Usually you cannot update/write L2 before data
>>> is allocated and written if you don't want to get a L2 entry pointing
>>> to garbage or unwritten data (if physically you write to a sector you
>>> get new data or old one on fail, not data changing to anything else).
>>> The exception to this is when even L2 table is not allocated. In this
>>> case you can write L2 table with data cause in case of failure this
>>> new L2 table is just not attached to anything (cause L1 still point to
>>> old L2 or is not allocated). My patch can collapse these two cluster
>>> writes in a single one. The key point of the patch is mainly
>>> collapsing all writes as you can not blocking other writes if not
>>> needed.
>>
>> Ok, I see.
>>
>> Not sure if it makes any measurable difference. With 64k clusters, an L2
>> allocation happens only every 512 MB. But if it's not much code to
>> support it, it's probably a good thing.
>>
> 
> Let's see :)
> 
> I published a repo at gitorious. https://gitorious.org/qemu (yes, qemu
> was free for me :) )

Pretty radical changes. :-)

I didn't really read most of the code (yet), but I gave it a try and ran
an iozone benchmark with it. It seems to degrade cluster allocation
performance to about the level of qcow2 in 0.12.4.

The numbers say that you get about 40% of git master throughput on large
block sizes (256k), and 65% of git master throughput on small ones (8k).
So you may really have triggered some special cases that only apply for
qemu-io/qemu-img.

Kevin