Re: [Qemu-devel] qcow2x

[Kevin Wolf]

Am 05.08.2011 15:16, schrieb Frediano Ziglio:
> 2011/8/5 Kevin Wolf <address@hidden>:
>> Am 03.08.2011 15:39, schrieb Frediano Ziglio:
>>> 2011/8/2 Kevin Wolf <address@hidden>:
>>>> 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
>>
> 
> I'll try iozone too. I have still to try real tests. It seems that
> many performance boost I can get with qcow2x can be implemented
> without changing so much code in qcow2. Perhaps I posted my code too
> much earlier. Which iozone tests are you running?

The script I use creates a new file system for /mnt and runs this:

./iozone -f /mnt/test_8k -w -e -I -i0 -i1 -i2 -K -r 8k -s 64M
./iozone -f /mnt/test_256k -w -e -I -i0 -i1 -i2 -K -r 256k -s 1G

This is actually more than you really need. The interesting number for
measuring cluster allocation performance is sequential writes.

Kevin