From owner-freebsd-geom@FreeBSD.ORG Wed Jan 10 09:21:21 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 DC9CD16A412; Wed, 10 Jan 2007 09:21:21 +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 628E913C47E; Wed, 10 Jan 2007 09:21:21 +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 ) id 1H4Ze0-000Mhh-Ci; Wed, 10 Jan 2007 10:21:16 +0100 Message-ID: <45A4B03A.5030806@fluffles.net> Date: Wed, 10 Jan 2007 10:22:02 +0100 From: Fluffles User-Agent: Thunderbird 1.5.0.8 (X11/20061114) MIME-Version: 1.0 To: unixtools@hotmail.com References: <45A38D38.3020407@fluffles.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 09:21:22 -0000 Hello list, Thanks for all your input. After some thought about I/O tracing, I guess ktrace won't work properly. I do not see the offset/length of the requests and it does include the actual contents; so it's not what i need. I think the geom_nop approach might be the best or most simple. Arne Woerner provided me a modified gnop which logs the I/O requests at debuglevel 0. But i would need some form of binary logging, to file. So that with a specially modified gnop it would dump all I/O into a file, like: /mnt/memorydisk/ad4.nop.log. It would have to log all accesses binary. I think i will drop the time between requests, so i will just need the serial order of requests and the following information: - read or write - offset - length It should be binary, like: R<32-bit offset><32-bit length>W<32-bit offset><32-bit length>.... The R means Read (so takes 1 byte) and W ofcourse write. This way it will take 9 bytes per I/O request to log. I could log to memory (md malloc) to minimize performance penalty. The logging should be able to turn off/on via sysctl switch or so, so i can prepare the benchmark setup and turn on tracing just before i launch the application i wish to trace. When this modified gnop module is done, i need a C-like program that can read the log and perform the I/O on a given device. Such as calling the following command: ./tracereproduce ./tracereproduce /mnt/memorydisk/ad4.nop.log /dev/raid5/test Then it would execute all I/O requests logged in the .log file at the fastest speed possible, serially. It should record the start time and end time and calculate the microtime it has used to finish all requests. Say this is 14.9 seconds for 20.000 I/O requests, then it would produce 1342 I/O per second as the end result. Then i can reproduce the test on say a gmirror device and i would get another score, being able to compare between classes. What do you guys think? Any flaws in my idea? I know this is at geom level and not VFS-level, but as Arne Woerner pointed out to me; caching/buffering that happens at the VFS-level will never reach the geom-layer anyway; so i do not need it. All benchmarking will be done on one machine so the only thing different is the geom classes; for example a 4-disk gstripe versus 4-disk graid5, etc. There might be better ways to do tracing; but since i'm a simple webdeveloper i do not have the skills to write a sophisticated applications. The geom-tracing approach outlined above might be my best option and might come very close to realistic performance-gains. Feedback is appreciated. :) - Veronica