Peter Staubach wrote:
> david m. richter wrote:
>>> Now, if someone was proposing a way to do "nfsstat 5" and make the
>>> output look useful, then I would be behind that 100%.
>>>
>>>    Thanx...
>>>
>>>       ps
>>>     
>>
>> 	do you mean "gather stats for the next 5 seconds"?  i don't 
>> understand the arg.
> 
> Sorry, I should have been more explicit.  I have wished for
> something that would behave like "vmstat 5", ie. print nfsstat
> statistics in some sort short hand fashion once every few
> seconds, 5 in this example.
> 
> The problem has always been that there are too many operations
> for summarize them on one line in any sort of interesting way.
> This becomes particularly true for NFSv4 which has its multitude
> of operations...
> 
> Perhaps we should just bite the bullet and produce the large
> output, much like "iostat 5" seems to.

First, thanks to David and the citi guys for the patches.

The kernel stats themselves should never be zeroed except by umount or 
reboot.  Otherwise, tools like "sar" and "iostat" that are looking 
directly at the same set of kernel stats, and producing a "one every 5 
seconds" type of output, would be totally confused if "nfsstat -z" 
actually cleared the kernel counters.

There's a bigger picture here.  nfsstat does not live in a vacuum, it 
lives in the presence of all the other I/O tools like sar, vmstat, and 
iostat.  For that matter, we already have "watch nfsstat" and 
"nfswatch".  Those tools already provide a "once every 5 seconds" type 
of interface.  I might even be inclined to argue that adding "once every 
5 seconds" type functionality is really outside of nfsstat's job 
description.

So if we wanted an "nfsstat --since" or "nfsstat 5 5" kind of thing, 
maybe we should think about the other tools, how they fit in, and how 
they work, and see if we can use one of them for that.  Even better, a 
GUI like gnome-system-monitor would be very nice for watching NFS client 
and server performance in real time.

I'm kind of tired of NFS living in its own little world with regard to 
the other file systems.  The NFS performance metrics I built were 
precisely for the purpose of making NFS a "first class" file system with 
regard to reporting errors and performance, and for the purpose of 
including NFS in the tools sysadmins normally use to watch I/O subsystem 
  performance data on local disks.

Can we come up with a plan that moves NFS closer to other file systems?