Am 05.08.2011 15:16, schrieb Frediano Ziglio: > 2011/8/5 Kevin Wolf <kw...@redhat.com>: >> Am 03.08.2011 15:39, schrieb Frediano Ziglio: >>> 2011/8/2 Kevin Wolf <kw...@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. >>>> >>> >>> 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