From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mn6YA-00062w-08 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 04:04:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mn6Y5-00060O-HI for qemu-devel@nongnu.org; Mon, 14 Sep 2009 04:04:37 -0400 Received: from [199.232.76.173] (port=48704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mn6Y5-00060I-AF for qemu-devel@nongnu.org; Mon, 14 Sep 2009 04:04:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58135) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mn6Y4-0003o4-M8 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 04:04:32 -0400 Message-ID: <4AADF8CA.3050800@redhat.com> Date: Mon, 14 Sep 2009 10:03:22 +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> <4AAA58E1.7040709@redhat.com> <20090911184045.GD13621@lst.de> In-Reply-To: <20090911184045.GD13621@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 Am 11.09.2009 20:40, schrieb Christoph Hellwig: > On Fri, Sep 11, 2009 at 04:04:17PM +0200, Kevin Wolf wrote: >>> 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.. >> >> What happened with this patch, Christoph? I just looked at the tests >> again and found that we're still aligning our test requests for 4k clusters. > > I't been a while.. Wasn't this the one that took so long that it > didn't complete even in a few hours? Hm, might be. However, not testing the critical points is really bad. If we hit any interesting case with the current tests, it's pure luck. What we can do is to reduce the number of write requests. In theory, just one request for each case should be enough. However, if we change the test in this way, we would lose a test doing lots of small writes. Maybe an additional test instead that aligns it requests according to the cluster size? Kevin