Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!decwrl!sgi!brendan@illyria.wpd.sgi.com
From: brendan@illyria.wpd.sgi.com (Brendan Eich)
Newsgroups: comp.sys.sgi
Subject: Re: /usr/etc/nfsstat interpretation
Summary: Soft mounts can time out; use hard or longer timeouts
Message-ID: <45861@sgi.sgi.com>
Date: 6 Dec 89 21:47:23 GMT
References: <8912051828.AA11401@uxe.cso.uiuc.edu>
Sender: brendan@illyria.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 38

> 	I have a 4D/240 server that is being used as a NFS and Yellow Pages
> server for a lab of 20 Personal Irises.  Lately, we've been experiencing a
> lot of problems with NFS "getattr" failures.  I looked at the output of the
> /usr/etc/nfsstat but am not sure what I am looking for or how to determine if
> it is the server or a client having a problem, and if it is a client, how do
> I find out which of the 20 PIs is having the problem.  Could someone help me 
> interpret the following nfsstat output?  Thanks!

When you write "getattr" failures, do you mean this message came out on
the client's console?

	NFS getattr failed for server XXX: Connection timed out

If so, the client is soft-mounting the server's filesystem(s).  A hard mount
never times out.  The nfsstat numbers confirm this:

> Client rpc:
> calls      badcalls   retrans    badxid     timeout    wait       newcred
> 316821     322        105        9          266        0          0          
>
> Client nfs:
> calls      badcalls   nclget     nclsleep
> 316821     322        316821     0          

The 9 badxids suggest that the server got behind the client: old replies
came back after the calling client process had timed out, and new calls
waiting for their replies noted the old replies' transaction identifiers
(xids) as "bad".

The 266 timeouts indicate an overloaded server, sick Ethernet, or some
similar problem.  Try mounting with a larger initial timeout (the timeo
mount(1M)/fstab(4) option), and/or retransmission attempt limit (retrans).
Use netstat(1) to check for input/output errors detected by the network
interface, which might indicate a sick Ethernet.

Brendan Eich
Silicon Graphics, Inc.
brendan@sgi.com