Re: [Qemu-devel] qcow2x

[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.

>>> - data/l2 are allocated sequentially (if there are not hole freed) but
>>> written in another order. This cause excessive file fragmentation with
>>> default cache mode, for instance on xfs file is allocated quite
>>> sequentially on every write so any no-sequential write create a
>>> different fragment.
>>>
>>> Currently I'm getting these times with iotests (my_cleanup branch is
>>> another branch more conservative with a patch to collapse reference
>>> decrement, note that 011 and 026 are missing, still not working)
>>
>> Note that qemu-iotests is often a good indicator, but the tools often
>> show different behaviour from real guests, so you should also run
>> benchmarks in a VM.
>>
> 
> I know, one reason is that guest usually do a lot of small write/read
> (probably this is how hardware work but I don't know this side that
> much, usually I didn't see request longer than 128 sectors).
> 
>>>     X    C    B
>>> 001 6    3    7
>>> 002 3    3    4
>>> 003 3    3    3
>>> 004 0    1    0
>>> 005 0    0    0
>>> 007 35   32   36
>>> 008 3    4    3
>>> 009 1    0    0
>>> 010 0    0    0
>>> 012 0    0    2
>>> 013 125  err  158
>>> 014 189  err  203
>>> 015 48   70   610
>>> 017 4    4    4
>>> 018 5    5    5
>>> 019 4    4    4
>>> 020 4    4    4
>>> 021 0    0    0
>>> 022 74   103  103
>>> 023 75   err  95
>>> 024 3    3    3
>>> 025 3    3    6
>>> 027 1    1    0
>>> 028 1    1    1
>>>
>>> X qcow2x
>>> C my_cleanup
>>> B kevin/coroutine-block
>>>
>>> Currently code is quite "spaghetti" code (needs a lot of cleanup,
>>> checks, better error handling and so on). Taking into account that
>>> code require additional optimizations and is full of internal
>>> debugging time times are quite good.
>>>
>>> Main questions are:
>>> - are somebody interesting ?
>>> - how can I send such a patch for review considering that is quite big
>>> (I know, I have to clean a bit too) ?
>>
>> You'll need to split it up into reviewable pieces. But let me have a
>> look at your git tree first.
>>
> 
> I have an account on gitorious but still my repo is only local. Do you
> suggest a different provider or gitorious is ok for you?

Works for me. Just anything that I can pull from.

>> Are you in the #qemu IRC channel? I think we should coordinate our qcow2
>> work a bit in order to avoid conflicting or duplicate work.
> 
> No, I don't use irc that much (time shift problems and also connection
> too). When are you online?

Usually until something like 18:00 CEST (16:00 UTC).

Kevin