ufsstat - testers / feedback wanted!

Max Laier max at love2party.net
Thu Oct 13 05:11:27 PDT 2005


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

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.

> 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.

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.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20051013/45b67e11/attachment.bin


More information about the freebsd-current mailing list