From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoH55-00065n-79 for qemu-devel@nongnu.org; Tue, 02 Aug 2011 11:40:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoH53-0001D8-Td for qemu-devel@nongnu.org; Tue, 02 Aug 2011 11:40:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoH53-0001D1-LJ for qemu-devel@nongnu.org; Tue, 02 Aug 2011 11:40:29 -0400 Message-ID: <4E381B1C.2020305@redhat.com> Date: Tue, 02 Aug 2011 17:43:24 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4E381247.1000008@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qcow2x List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frediano Ziglio Cc: qemu-devel 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