From owner-freebsd-geom@FreeBSD.ORG Tue Jan 9 14:43:44 2007 Return-Path: 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 6117D16A492 for ; Tue, 9 Jan 2007 14:43:44 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E9B0C13C471 for ; Tue, 9 Jan 2007 14:43:43 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H4ICS-00010j-TV for freebsd-geom@freebsd.org; Tue, 09 Jan 2007 15:43:40 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Jan 2007 15:43:40 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Jan 2007 15:43:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Tue, 09 Jan 2007 15:43:33 +0100 Lines: 45 Message-ID: References: <45A38D38.3020407@fluffles.net> <45A396C5.2000908@fluffles.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <45A396C5.2000908@fluffles.net> Sender: news Cc: freebsd-fs@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 14:43:44 -0000 Fluffles wrote: > 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 If an application has two threads (or there are two processes) making a request at the same time, the lower level WILL get two requests, even if the "first one" hasn't completed. This is nondeterministic - you can't know which application's request will be the "first" and on the GEOM level you don't know what application has made the request. It's all anonymous I/O at that level, completed asynchronously. Is this what you're asking or is it something else? > 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. Nobody is questioning the use of I/O traces for benchmarking - I've seen many utilities that do it. Of course, raw I/O traces are only useful for benchmarking raw I/O - more useful for most workloads would be VFS traces (because it involves CPU, locking, etc...).