qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qcow2x


From: Frediano Ziglio
Subject: Re: [Qemu-devel] qcow2x
Date: Fri, 5 Aug 2011 15:16:16 +0200

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?

Frediano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]