Subject: NFS MIB ideas

From: Venkat Rangan <[email-masked]>
Date: Wed, 14 Mar 2001 16:42:21 -0800

All,

We are looking to add SNMP manageability for NFS entities, along the lines
of several other protocols.

I created a very early version of the MIB which covers the following areas:

- Error counters that count the number of occurrences of almost all errors

- Statistical counters for all the NFS v4 operations

- Table of current locks and their owners

I missed the I-D draft submission deadline, so I've posted the above MIB
here. This will be submitted to the I-D list when it opens for new
submissions.

http://www.rhapsodynetworks.com/MIBS/draft-rangan-nfsv4-mib-00.txt

Some of the design issues we need to address are:

1. Do we need to also handle v2 and v3 protocol implementations?

2. Do we need a separate MIB for RPC layer?

3. How much configuration and operation-level objects do we need?

4. Object model for the MIB, along the lines of iSCSI.

5. Does it make sense to have a MIB for the client side as well?

6. Besides 'nfsstat' like statistics, what other measurements are most
useful? Is it interesting to include 'Response Time' measurements?

7. Conformance levels and object grouping to support flexible conformance
levels.

Thanks,

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

---

From: Brent <[email-masked]>
Date: Thu, 15 Mar 2001 18:19:23 -0800

Venkat Rangan wrote:

> - Table of current locks and their owners

I'm a neophyte to MIB design, but it seems that you should design
a MIB so that it provides access to data that an NFS administrator needs.

I'm an NFSv4 engineer, so error and operations counts would
be lovely, but it doesn't seem all that useful to an NFS sysadmin
no matter how much you process the data.

My guess is that admins would be interested in higher-level
statistics, e.g. which filesystems are hot? which clients
are beating on my server? what's the average call processing
time? How many bytes/sec are being read/written?

> 1. Do we need to also handle v2 and v3 protocol implementations?

I think most v4 servers will also support v2 and v3.  It would be
an obvious omission not to support those versions too.

> 2. Do we need a separate MIB for RPC layer?

Yes.  That would be a good place to accumulate things
like duplicate request counts, bad xids etc.

> 3. How much configuration and operation-level objects do we need?

I'm not sure of the distinction.  Can you give examples?

> 4. Object model for the MIB, along the lines of iSCSI.

That would be interesting.  Is there an iSCSI MIB we can look at?

> 5. Does it make sense to have a MIB for the client side as well?

Yes.

> useful? Is it interesting to include 'Response Time' measurements?

nfsstat provides a minimal set of NFS statistics.  For Solaris, you can
get per-mount statistics on the client, but not per-share statistics
on the server.  I think a MIB could provide more useful statistics.

> 7. Conformance levels and object grouping to support flexible conformance

Sounds some kind of MIB compliance model.  You may need to educate us.

	Thanks
		Brent

---

From: "Matthew J. Zito" <[email-masked]>
Date: Fri, 16 Mar 2001 00:00:29 -0500

>1. Do we need to also handle v2 and v3 protocol implementations?

I think it would be the ideal situation if you did - it would allow a 
single MIB to handle all the NFS traffic for a server.

>3. How much configuration and operation-level objects do we need?

Including configuration information gets a bit dicey in my mind - 
there's a lot of sensitive information that gets included in a 
standard configuration.  A lot of organizations don't protect their 
read-only community strings very well, figuring that the amount of 
information that could be gleaned would be relatively inocuous.

Also, do NFS server configurations change enough that they need 
management via snmp?  I can think of times when it might be useful, 
but in all of those cases, I could see using some other method to 
update the configuration.

>5. Does it make sense to have a MIB for the client side as well?

Sure does.  There's a lot of situations where you want the 
granularity of looking at the client.

>useful? Is it interesting to include 'Response Time' measurements?

Response time would be useful - actually, a good place to start would 
be looking at all the information "sar" provides.  Similar 
functionality like "average time per transaction" would be very 
useful.

Beyond that, if you could get information about individual clients - 
information about what filesystems they're mounting, what files they 
access the most, how often the data they request is in cache, and 
individual client nfs operation deltas, to name a few, it would 
fulfill a definite need.  I realize that from a software standpoint, 
trying to keep all of these statistics could place a heavier load on 
the server.  So, have an object that specifies whether or not those 
statistics are being tracked  - that way implementation of this 
information is optional, and even when implemented, no one is 
obligated to track that information. The extra info could be turned 
on when you're trying to find specific addditional data - like 
verifying that no client is mounting exported directory X before you 
rm -rf it.

Thanks,
Matt

-- 
Matthew J. Zito
Systems Engineer
Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018
Ph: 212-798-9205
PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC  D2 06 B2 B0 BF 55 68 99

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 15 Mar 2001 22:02:30 -0800

"Matthew J. Zito" wrote:
> The extra info could be turned

Actually, there's no easy way for a NFS server to establish whether a
client
has a filesystem mounted. NFS version 4 keeps track of which clients
have file open, or which locks are held - but not whether the client
has a filesystem "mounted".

	Brent

---

From: "Matthew J. Zito" <[email-masked]>
Date: Fri, 16 Mar 2001 11:40:19 -0500

>has a filesystem "mounted".

Mmmmm...good point.  What if the mounting of a directory was treated 
as a directory-level lock?  When the client mounts the directory, it 
could place a lock on the directory that simply indicates that it has 
it mounted.  An umount request could remove the lock.  Looking at the 
RFC, it looks as though the LOCK definition only allows for file 
locking.  If it was modified to permit a directory entry also, the 
server could have information about which clients consider which 
directories mounted.

Thanks,
Matt

---

From: Brent <[email-masked]>
Date: Fri, 16 Mar 2001 17:33:25 -0800

"Matthew J. Zito" wrote:
> What if the mounting of a directory was treated

You wouldn't want to lock a directory - just flag it in some
way to indicate that it is "in use".  What do you do when the
client reboots and forgets which servers it had mounted when
it died?  You could put a lease on the flag, but that would
require a client to periodically "ping" the server to keep
the lease alive - even when the mount wasn't in use. That
would be a bad idea.

A better idea might be to have the server keep track of
which clients have used the filesystem "recently" and
give the sysadmin access to that information.  No protocol
changes are required for that.

	Brent

---

From: "Matthew J. Zito" <[email-masked]>
Date: Fri, 16 Mar 2001 22:43:54 -0500

>changes are required for that.

Mmm - I don't mean lock, as in "lock for writing", I mean a LOCK_RT 
on the directory itself - that would indicate to the server that the 
directory should be considered "mounted".  The lock would be simply 
for informational purposes, and could be handled in the same way as 
any other lock.  If a better way to do that would be to implement an 
"in use" flag, that would be fine - I was just thinking that doing 
this within the existing structure of the protocol would be useful.

When a client reboots, the client has to have a knowledge of what 
filesystems to mount anyway - so it doesn't matter that it previously 
had it mounted - it'll just re-lock the directory when its mounted.

Server-side access tracking would be equally useful, but would serve 
a different purpose.  Any reasonable list of recently-accessed files 
on a per-client basis could quickly hide the filesystem information. 
The point of keeping track of mounts is to allow the server 
administrator to monitor who is mounting what directories and when, 
something that is very useful, and not available.

Thanks,
Matt

---

From: Brent Callaghan <[email-masked]>
Date: Sun, 18 Mar 2001 13:42:34 -0800

> something that is very useful, and not available.

Currently we do have this kind of client mount tracking on the
server via the mount protocol and the /etc/rmtab file. The
mount protocol has "mount" and "unmount" calls. When a client
mounts a v2 or v3 filesystem, the mount is recorded in the
/etc/rmtab file.  When the client unmounts, the mount record
is removed. Administrators can remotely query this mount list
via a UNIX showmount -a command.

In practice, the list is terribly unreliable.  Clients frequently
do a bunch of mounts, then crash, leaving a stale entry in
the /etc/rmtab file.  If a client is removed from the network
or fails to mount/unmount the filesystem again, then the entry
stays in the /etc/rmtab file permanently.

The only realistic way to deal with these stale entries is to
have the entries bound by some kind of lease that the client
must periodically renew, or to have the server callback the
client to see if its mount entry is still valid.  Either way,
it's extra baggage on the protocol.

I still prefer the "who has accessed this filesystem recently"
method.  It doesn't need any protocol changes and works for
all versions of NFS.  Sure, it doesn't deal well with the client
that mounted a filesystem last week and hasn't used it since,
though even that could be handled by aggregating the "recently
used" lists over a period of time.

	Brent

---

From: David Robinson <[email-masked]>
Date: Sun, 18 Mar 2001 21:42:40 -0800

> used" lists over a period of time.

A more obvious, and useful value, would be a list of all clients
with active connections to the server (not so useful for UDP).
As a user, I usually just want to know "who is banging my server
so hard it hurts", not "who all might have a file handle that might
use it some time in the future".

This is something that is trivial to put in a MIB, just dump the
active connection endpoints, and very useful.

	-David

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 19 Mar 2001 10:32:10 -0500

I'm loathe to require a lock be held indefinitely.  File locking is
generally used for brief periods to atomically update a file or to
guarantee a file remains unchanged whileit is being accessed.

I assume you're talking about a read lock.  Therefore, if some other
application wants to write lock a directory, say for updating several files
that make up a database, to prevent other database clients from seeing
an inconsistant directory, that won't work on NFS.

In later mail you note:

  Mmm - I don't mean lock, as in "lock for writing", I mean a LOCK_RT 
  on the directory itself - that would indicate to the server that the 
  directory should be considered "mounted". 

What's LOCK_RT?  I don't see it in rfc3010 or in Tru64 kernel sources.
Ditto LOCK_RD, if that's what you meant.

	-Ric Werme

---

From: Brent Callaghan <[email-masked]>
Date: Mon, 19 Mar 2001 08:12:05 -0800

> active connection endpoints, and very useful.

Yes, that might be usefully added to the RPC MIB.

	Brent