From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:28:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346D816A41F for ; Thu, 13 Oct 2005 13:28:13 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD6F443D48 for ; Thu, 13 Oct 2005 13:28:12 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j9DDSB9i080698; Thu, 13 Oct 2005 08:28:11 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434E60D6.3030402@centtech.com> Date: Thu, 13 Oct 2005 08:27:50 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> In-Reply-To: <200510131412.23525.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1131/Wed Oct 12 15:35:32 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 13:28:13 -0000 Max Laier wrote: > On Thursday 13 October 2005 13:36, Eric Anderson wrote: > >>[resend to -current for broader test audience] >> >>I've just finished the first version of ufsstat, a tool to show local >>filesystem statistics much like nfsstat does for NFS. The patch and >>tool is against 6.0, but it will probably apply and work fine under >>-CURRENT and possibly 5.x as well. >> >>I'm looking for bug reports, comments/suggestions on style(9), and >>anything else, since this is my first C project, and of course first >>real FreeBSD contribution. :) > > > The patch contains some jitter in the first three or four files due to older > versions in src-patched. As all the statistic gathering is #ifdef'ed it > should not hurt performance in the disabled case. It will look nicer if you > define a macro to update statistics like: > > #ifdef UFS_STATS > #define UFS_STATS_UPDATE(field) ufsstats.field++ > #else > #define UFS_STATS_UPDATE(field) > #end > > This will in turn only use one line per update point and you don't have to do > the ugly: > #ifdef UFS_STATS > ufsstats.fsync++; > #endif Thanks - great suggestion! I'll do that. Any ideas how to remove the FBSDID line jitter from the patches? I mean a 'correct' way - I could easily do it with some hacks/scripts/etc, but maybe there is a better way to do this. > Also, make sure to declare "extern struct ufsstats ufsstats" in ufsstats.h > under _KERNEL and define it in just one place. As is, you don't record the > updates from ffs_vnops.c into the right structure. Finally, you should > consider 64 bit counter for some, if not all, fields as they will overflow > quickly. Ok - I'm looking at that now. For the 64bit counters, I can only guess at most of the ones that will be used a lot, so is the correct way to do this to be very conservative and set most to type int, and the ones I think will be large, to int64_t, or just set them all to 64bit and be done with it? >>To use it, do this: >>cd /tmp >>fetch http://www.googlebit.com/software/ufsstat/ufsstat-20051011.tar.gz >>cd /usr >>tar xvzf /tmp/ufsstat-20051011.tar.gz >>patch <./ufsstats.patch >> >>add: >>OPTIONS UFS_STAT >>to your kernel. >> >>Rebuild and install world/kernel. >> >>Now, you can use ufsstat to show you statistics from your local >>filesystems, like this: >> >># ufsstat >> Create Remove Link Symlink Mkdir Rmdir Rename >> 289048 794043 4361 12558 25796 117739 0 >> GetAttr SetAttr Open Close ReadDir ReadLink VInit >> 64868230 759824 10701553 9891642 5042948 0 45315645 >> Chmod Chown Whiteout Strategy Access Mknod NewInode >> 409782 79612 0 4020035 0 3 0 >> Fsync SyncVnode LockVnode RdVnode WrVNode >> 0 0 0 0 0 >> ExtRead Extwrite FndExtAtt RdExtAttr OpnExtAtt ClseExtAt ExtStrtgy >> 0 0 0 0 0 0 0 >> >>or watch over time with the -w switch. >> >>I have not done any performance testing yet to see if it impacts >>filesystem performance by any measurable amount, so if someone does do >>this testing before I do, please post your results! > > > I don't think you can measure one single interger (or 64bit) increase in face > of a operation that has to access backing store. Even if there is a > performance hit, you don't have to build your kernel with the option enabled. I was thinking of doing some accumulative tests - say 10000 various operations without, then those same ops (in the same order, on the same disk, freshly newfs'ed again) with it enabled. > It might be (more) interesting to have these stats on a per-mountpoint basis. > Not sure if you have enough state available to record all of the above, but > since you asked for input - this might be worth investigating. I agree, and have thought about that. I expected this would be the first feature someone ask about. :) I'm not sure if it would be best to store all filesystems someone in one sysctl area, or have a sysctl for each mounted filesystem, or something else. Remember, I'm *very new* to this, so any hints or poking in the right direction is very helpful! Thanks for the input so far! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------