From: Steve Dickson <SteveD@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "'nfs@lists.sourceforge.net'" <nfs@lists.sourceforge.net>
Subject: Re: [PATCH 0/7] nfsstat: adding -D/--diff-stat to nfsstat
Date: Wed, 01 Aug 2007 17:50:32 -0400 [thread overview]
Message-ID: <46B10028.8080106@RedHat.com> (raw)
In-Reply-To: <20070801204824.GI13441@fieldses.org>
J. Bruce Fields wrote:
>
> Does it look like the nfsstat --sleep/--diff-stats/whatever would have
> done the job in the cases you're thinking of?
It would a bit more awkward... but I'm sure I could make it work...
>
>>> But I'd still object, for the same reasons; global zeroing of the in-kernel
>>> stats is an operation that:
>>>
>>> - isn't friendly to concurrent processes gathering stats:
>>> someone might want to run a cron job that summarizes the day's
>>> nfs stats, but still be able to log in and get a quick
>>> snapshot of current activity.
>> So then don't zero them out... and if some one comes a long and
>> does zero them out, thats a communication problem.. not a
>> technical one... ;-)
>
> What would you tell them to do instead? Parsing the nfsstat output and
> doing the subtraction yourself is a little tedious, so it's not
> suprising if they both try to use -z, if that's all we provide.
A *little* tedious??? :-) I don't know how I would tell them
to solve that problem esp with the current tools... I would
probably tell to see if they could get the mountstats numbers
to do what they wanted... and then tell them to send me the patch! 8-)
>
> Which is why I'd really rather not even emulate zeroing in userspace,
> and instead have two alternatives:
>
> - --sleep: quick and convenient, no concurrency problems.
>
> - --since: or other operations that do the subtraction for you
> and take explicit paths for saved snapshots. That allows you
> to do everything you could do with -z and more, and makes any
> problems with concurrency or privileges solvable by choice of
> appropriate paths to store the snapshots in.
Understood and I can see how these would be useful in
long term system analyzation but they would be awkward for
short term system debugging... which I think is the real difference
in these approaches...
>
> Actually the only operation you *really* need is one that parses two
> nfsstat outputs and subtracts:
>
> nfsstat >tmp1
> ...
> nfsstat >tmp2
> nfsstat --diff tmp1 tmp2
>
> and then anything else you can easily script.
Personally I would make the output binary (with a -b flag) since
it seem like it would be easier to do binary compares than
string... But of course that would be giving you more ammo
and I would not want to do that... ;-)
>
>>> But I think more snapshot-and-diff operations would be a fine idea.
>>> And probably easy and fun to implement.
>> Why not point that snapshot at /proc/self/mountstats? Those stats
>> will never be zero and the wealth of information in there truly
>> an untaped gold mine....
>
> Yeah, that'd be great. We'll still need nfsstat for the server at
> least, I guess?
Good point...
> Does it still provide anything useful on the client
> side, or does mountstats supercede it completely?
I think the both are needed since they provide different
types of information... The nfsstat stats are basically
"hello world" counters that show there is NFS activity....
The mountstats are much more granular and are per mount
which could be used to for many different things... like
server responsive for an example...
steved.
-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-08-01 21:50 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 21:38 [PATCH 0/7] nfsstat: adding -D/--diff-stat to nfsstat david m. richter
2007-07-31 22:11 ` Neil Brown
2007-07-31 23:29 ` david m. richter
2007-07-31 23:41 ` J. Bruce Fields
2007-08-01 0:42 ` Neil Brown
2007-08-01 11:55 ` Peter Staubach
2007-08-01 15:59 ` david m. richter
2007-08-01 16:49 ` Trond Myklebust
2007-08-01 17:07 ` J. Bruce Fields
2007-08-01 17:42 ` david m. richter
2007-08-01 16:50 ` J. Bruce Fields
2007-08-01 17:35 ` david m. richter
2007-08-01 17:41 ` J. Bruce Fields
2007-08-01 17:45 ` david m. richter
2007-08-01 17:46 ` Trond Myklebust
2007-08-01 17:48 ` david m. richter
2007-08-01 18:02 ` Trond Myklebust
2007-08-01 18:12 ` david m. richter
2007-08-01 18:15 ` Muntz, Daniel
2007-08-01 18:37 ` david m. richter
2007-08-01 18:41 ` Trond Myklebust
2007-08-01 18:47 ` david m. richter
2007-08-01 18:50 ` J. Bruce Fields
2007-08-01 20:03 ` Steve Dickson
2007-08-01 20:48 ` J. Bruce Fields
2007-08-01 21:50 ` Steve Dickson [this message]
2007-08-01 22:40 ` Trond Myklebust
2007-08-01 18:38 ` J. Bruce Fields
2007-08-01 17:52 ` J. Bruce Fields
2007-08-01 17:55 ` Peter Staubach
2007-08-01 18:14 ` david m. richter
2007-08-01 18:22 ` Peter Staubach
2007-08-01 18:25 ` david m. richter
2007-08-01 18:57 ` J. Bruce Fields
2007-08-01 19:35 ` Chuck Lever
2007-08-01 20:16 ` Steve Dickson
2007-08-01 20:54 ` Chuck Lever
2007-08-01 19:42 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B10028.8080106@RedHat.com \
--to=steved@redhat.com \
--cc=bfields@fieldses.org \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.