From: Greg Banks <gnb@melbourne.sgi.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Charles Lever <Charles.Lever@netapp.com>, nfs@lists.sourceforge.net
Subject: Re: [PATCH] 1/3 - RPC metrics support
Date: Fri, 02 Apr 2004 12:42:32 +1000 [thread overview]
Message-ID: <406CD318.F48841F3@melbourne.sgi.com> (raw)
In-Reply-To: 1080870078.10521.53.camel@lade.trondhjem.org
Trond Myklebust wrote:
>
> On Thu, 2004-04-01 at 19:49, Greg Banks wrote:
>
> > Why not just save a copy of @devname in nfs_get_sb() ?
>
> That is very different. That we can do...
>
> Please don't confuse the export path and the device name. nfss->mnt_path
> is the former:
> The device name OTOH is just whatever label the caller of sys_mount()
> feels like passing down to the kernel. It will usually contain the name
> of the server and the export path ('cos that's what the nfs-utils
> "mount" does), but it does not have to, and we currently do not depend
> on it taking any particular value.
If all we care about is identifying the sb for purposes of iostat and
post-mortem debugging (I for one would find this useful), the precise
semantics placed on the string by the mount program don't matter that
much. You could add a `devname' field to nfs_server and document
that it doesn't mean anything at all. Alternatively you could check
that the first part matches (modulo domain names) the `hostname' field
and is followed by a ':' and a path, and if all that matches, save the
path.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-04-02 2:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 17:05 [PATCH] 1/3 - RPC metrics support Lever, Charles
2004-04-02 0:17 ` Greg Banks
2004-04-02 0:36 ` Trond Myklebust
2004-04-02 0:49 ` Greg Banks
2004-04-02 1:41 ` Trond Myklebust
2004-04-02 2:42 ` Greg Banks [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-04 2:35 Lever, Charles
2004-04-04 6:17 ` Greg Banks
2004-04-01 16:45 Lever, Charles
2004-04-02 0:10 ` Greg Banks
2004-04-01 15:15 Lever, Charles
2004-04-01 23:58 ` Greg Banks
2004-04-02 0:34 ` Trond Myklebust
2004-04-02 2:33 ` Greg Banks
2004-03-31 16:57 Lever, Charles
2004-03-31 17:19 ` Trond Myklebust
2004-03-31 16:34 Lever, Charles
2004-03-31 16:46 ` Trond Myklebust
2004-04-01 8:13 ` Greg Banks
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=406CD318.F48841F3@melbourne.sgi.com \
--to=gnb@melbourne.sgi.com \
--cc=Charles.Lever@netapp.com \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox