From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJ784-000454-H5
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:37:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJ77z-0003xu-TI
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:37:43 -0400
Received: from [199.232.76.173] (port=55388 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJ77z-0003xH-9C
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:37:39 -0400
Received: from mx2.redhat.com ([66.187.237.31]:56955)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1MJ77y-0000W0-P7
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 10:37:39 -0400
Message-ID: <4A40E86D.9060907@redhat.com>
Date: Tue, 23 Jun 2009 16:36:29 +0200
From: Kevin Wolf <kwolf@redhat.com>
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>
In-Reply-To: <20090623143105.GA17748@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Christoph Hellwig schrieb:
> On Tue, Jun 23, 2009 at 11:16:21AM +0200, Kevin Wolf wrote:
>> About the qcow2 tests there is one thing to note: These test cases use
>> hard coded offsets which were calculated for 4k clusters. For 64k
>> clusters (which the default now) I'm almost sure they don't test the
>> critical points any more. So we'll need to change offsets dynamically
>> depending on the cluster size of the qcow2 image.
> 
> Or just run the test for all interesting cluster sizes to some more
> coverage (should be only 4k and 64k for now).

We could either always test both 4k and 64k or let the user choose on
the command line. Either way, this is unrelated to what I meant. I'm
talking about things like this:

    # Spanning multiple clusters
    io $op $((offset + 2048)) 8192 12288 64

This is a request spanning multiple 4k clusters, but for 64k clusters it
is just another write somewhere in the middle of the cluster. So with
64k we actually have worse coverage currently than with 4k clusters (and
we don't test 4k yet).

Kevin