All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "'nfs@lists.sourceforge.net'" <nfs@lists.sourceforge.net>,
	Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH 0/7] nfsstat: adding -D/--diff-stat to nfsstat
Date: Wed, 01 Aug 2007 18:40:13 -0400	[thread overview]
Message-ID: <1186008013.6700.244.camel@localhost> (raw)
In-Reply-To: <20070801204824.GI13441@fieldses.org>

On Wed, 2007-08-01 at 16:48 -0400, J. Bruce Fields wrote:

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

The entire point of 'nfsstat' is to act as a parser. Otherwise we'd just
be all be reading the raw output from /proc/net/rpc/*... It makes sense
to add other parsing options to it. I'm a lot more sceptical about
attempts to add non-parsing options.

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

Has nothing to do with parsing.

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

Parsing already-parsed output is IMO less useful. Just have it be able
to take input from somewhere other than just /proc/net/rpc/*

> > > 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?  Does it still provide anything useful on the client
> side, or does mountstats supercede it completely?




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

  parent reply	other threads:[~2007-08-01 22:40 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
2007-08-01 22:40                       ` Trond Myklebust [this message]
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=1186008013.6700.244.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=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.