From owner-freebsd-geom@FreeBSD.ORG  Tue Jan  9 13:20:30 2007
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
X-Original-To: freebsd-geom@freebsd.org
Delivered-To: freebsd-geom@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 6501216A412;
	Tue,  9 Jan 2007 13:20:30 +0000 (UTC)
	(envelope-from etc@fluffles.net)
Received: from auriate.fluffles.net (cust.95.160.adsl.cistron.nl
	[195.64.95.160])
	by mx1.freebsd.org (Postfix) with ESMTP id BAAA213C467;
	Tue,  9 Jan 2007 13:20:29 +0000 (UTC)
	(envelope-from etc@fluffles.net)
Received: from destiny ([10.0.0.21])
	by auriate.fluffles.net with esmtpa (Exim 4.63 (FreeBSD))
	(envelope-from <etc@fluffles.net>)
	id 1H4Gts-00052F-Ob; Tue, 09 Jan 2007 14:20:24 +0100
Message-ID: <45A396C5.2000908@fluffles.net>
Date: Tue, 09 Jan 2007 14:21:09 +0100
From: Fluffles <etc@fluffles.net>
User-Agent: Thunderbird 1.5.0.8 (X11/20061114)
MIME-Version: 1.0
To: Ivan Voras <ivoras@fer.hr>
References: <45A38D38.3020407@fluffles.net> <eo049r$th4$1@sea.gmane.org>
In-Reply-To: <eo049r$th4$1@sea.gmane.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org
Subject: Re: Capturing I/O traces
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: GEOM-specific discussions and implementations
	<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2007 13:20:30 -0000

Ivan Voras wrote:
> Fluffles wrote:
>
>   
>> One thought that comes to mind is the gnop geom class; with verbose mode
>> this provides a text log of all the I/O accesses. But it does not
>> provide the exact time/concurrency etc, only the offset, length, I/O
>>     
>
> What do you mean by "time" and "concurrency"? You do realize that
> requests are serialized on the low level?
>   

Sure but simply capturing the serial order of requests might not be
sufficient. For example: the application might 'wait' for one request to
be finished because it needs that data in order to do another I/O
request. I guess this is the hard part. If i would just execute the I/O
in a serial way things like accesstime or 'latency' are less important
because the overall throughput counts; while this may not be true for
real applications but they might wait on one request before they can
move on; thus a lower latency might be more important than a higher
throughput.

I guess it's not easy to really make something like this be reliable and
realistic, but i'd like to come as close as possible. For example, the
website StorageReview also uses traces to benchmark specific uses, two
links:

http://www.storagereview.com/articles/200611/ST3750640NS_3.html
http://www.storagereview.com/articles/200510/Testbed4_4.html

I'd like to use traces of applications on FreeBSD (or GNU/Linux) to
benchmark KDE startup, MySQL, Apache and other applications. So i can
have benchmark suites like "desktop", "webserver" and "database". That
would be very neat.