From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpKLK-0002Fl-FA for qemu-devel@nongnu.org; Fri, 05 Aug 2011 09:21:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpKLI-0003iB-SA for qemu-devel@nongnu.org; Fri, 05 Aug 2011 09:21:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpKLI-0003i0-Kz for qemu-devel@nongnu.org; Fri, 05 Aug 2011 09:21:36 -0400 Message-ID: <4E3BEF0F.6040303@redhat.com> Date: Fri, 05 Aug 2011 15:24:31 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4E381247.1000008@redhat.com> <4E381B1C.2020305@redhat.com> <4E3BE7A8.50409@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 05.08.2011 15:16, schrieb Frediano Ziglio: > 2011/8/5 Kevin Wolf : >> Am 03.08.2011 15:39, schrieb Frediano Ziglio: >>> 2011/8/2 Kevin Wolf : >>>> 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