Re: [PATCH 0/7] nfsstat: adding -D/--diff-stat to nfsstat

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

Steve Dickson wrote:
> Chuck Lever wrote:
>> 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.
> In general, I agree. Stats that "sar" and "iostat" see should
> not be zeroed.. but the nfsstat's stats do not fall in this
> category. They are more like counters than true statistics.
> I think if they were call nfscounts instead of nfsstats
> there would be less of an uproar since reseting counter
> is no big deal...
> 
> So in the end.. these counter are used to show nfs activity
> for the entire box... so being able to zero them would
> incredibly handy for developers and customers alike...
> 
> 
>>
>> 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?
> Yeah... lets build a tool that understand the stats in
> /proc/self/mountstats and continue build there... because imho,
> thats where the future lies with regard to understanding and
> analyzing NFS traffic patterns...

I think I agree with this overall approach.

Leave nfsstat alone (or maybe add "-z" to zero the traditional 
/proc/net/rpc/nfs), and add support for /proc/self/mountstats in sar, 
iostat, and vmstat.

That way you can have your zeroed counters a la Solaris, and also have 
counters that can't be zeroed for the tools that look for trends.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs