From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MO59q-0007iH-8b for qemu-devel@nongnu.org; Tue, 07 Jul 2009 03:32:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MO59m-0007Z1-58 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 03:32:05 -0400 Received: from [199.232.76.173] (port=39774 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MO59l-0007YR-IA for qemu-devel@nongnu.org; Tue, 07 Jul 2009 03:32:01 -0400 Received: from mx20.gnu.org ([199.232.41.8]:54298) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MO59k-0002Mv-Qd for qemu-devel@nongnu.org; Tue, 07 Jul 2009 03:32:01 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MO59k-0005Zn-59 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 03:32:00 -0400 Message-ID: <4A52F9A7.5020009@redhat.com> Date: Tue, 07 Jul 2009 09:30:47 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] the qemu-iotests test suite is now available References: <20090622210523.GA8024@lst.de> <4A409D65.3040104@redhat.com> <20090623143105.GA17748@lst.de> <4A40E86D.9060907@redhat.com> <20090623164130.GB27211@lst.de> <4A51DD6C.8030907@redhat.com> <20090706173606.GA2379@lst.de> In-Reply-To: <20090706173606.GA2379@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Christoph Hellwig schrieb: > On Mon, Jul 06, 2009 at 01:18:04PM +0200, Kevin Wolf wrote: >> I started to implement this, too. I'm attaching the current state of my >> version. It's not as complete (converts only io_test() and doesn't even >> enable different cluster sizes in the tests), but it's a pure 1:1 >> conversion and it remains compatible with the old test results which is >> a hint that it's right at least for 4k clusters. >> >> I haven't reviewed your patch in much detail, but I think my patch is >> more correct at least for the "spanning multiple L2 tables" case where >> you still use the old hard coded numbers. With 4k clusters an L2 table >> spans 2 MB, whereas with 64k clusters it spans 512 MB. > > You're right. > >> So maybe you just compare the two versions and take for each line >> whatever looks better suited for dynamic cluster sizes. > > Done. Below is a version of my original patch with you l2 cluster size > changes incorporate. The problem is that I really uses up tons of disk > space for the last test in io_test() for 64k clusters, in fact more than > I can make available on the laptop I'm travelling with currently.. I agree, we shouldn't do it this way. 512 MB is a lot and I've heard some people thinking about increasing the cluster size even more... So this doesn't only take too much disk space but also a huge amount of time for a simple test (crossing the L2 table border). So I think what we should do is to calculate the end of the current L2 table, go back a bit and write a small amount of data, just enough to cross the L2 border. Does that make sense? > # Spanning multiple L2 tables > # L2 table size: 512 clusters of 4k = 2M > - io $op $((offset + 2048)) 4194304 4999680 8 > - offset=$((offset + 8 * 4999680)) > - > - if false; then > - true > - fi offset=$(( ((offset + l2_size - 1) & ~(l2_size - 1)) - (3 * half_cluster) )) > + io $op $((offset + $half_cluster)) $((2 * l2_size)) 4999680 8 > + offset=$((offset + 8 * (2 * l2_size + 512 * 1573))) > } And then write 6 * half_cluster or something like that instead of 2 * l2_size. I guess you also should change 4999680 to something like l2_size + half_cluster, so we always hit an L2 border and test a few different cases. Completely untested, but I think it should work this way. Kevin