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
