Managing NFS and NIS, 2nd Edition - Mike Eisler [207]
Client rpc:
Connection oriented:
calls badcalls badxids timeouts newcreds badverfs
1753584 1412 18 64 0 0
timers cantconn nomem interrupts
0 1317 0 18
Connectionless:
calls badcalls retrans badxids timeouts newcreds
12443 41 334 80 166 0
badverfs timers nomem cantsend
0 4321 0 206
Client nfs:
calls badcalls clgets cltoomany
1661217 23 1661217 3521
Version 2: (234258 calls)
null getattr setattr root lookup readlink
0 0% 37 0% 0 0% 0 0% 184504 78% 811 0%
read wrcache write create remove rename
49 0% 0 0% 24301 10% 3 0% 2 0% 0 0%
link symlink mkdir rmdir readdir statfs
0 0% 0 0% 12 0% 12 0% 24500 10% 27 0%
Version 3: (1011525 calls)
null getattr setattr lookup access readlink
0 0% 417691 41% 14598 1% 223609 22% 47438 4% 695 0%
read write create mkdir symlink mknod
56347 5% 221334 21% 1565 0% 106 0% 48 0% 0 0%
remove rmdir rename link readdir readdirplus
807 0% 14 0% 676 0% 24 0% 475 0% 5204 0%
fsstat fsinfo pathconf commit
8 0% 10612 1% 95 0% 10179 1%
Client nfs_acl:
Version 2: (411477 calls)
null getacl setacl getattr access
0 0% 181399 44% 0 0% 185858 45% 44220 10%
Version 3: (3957 calls)
null getacl setacl
0 0% 3957 100% 0 0%
In addition to the total number of NFS calls made and the number of rejected NFS calls (badcalls), the client-side statistics indicate if NFS calls are being delayed due to a lack of client RPC handles. Client RPC handles are opaque pointers used by the kernel to hold server connection information. In SunOS 4.x, the number of client handles was fixed, causing the NFS call to block until client handles became available. In Solaris, client handles are allocated dynamically. The kernel maintains a cache of up to 16 client handles, which are reused to speed up communication with the server. The clgets count indicates the number of times a client handle has been requested. If the NFS call cannot find an unused client handle in the cache, it will not block until one frees up. Instead, it will create a brand new client handle and proceed. This count is reflected by cltoomany. The client handle is destroyed when the reply to the NFS call arrives. This count is of little use to system administrators since nothing can be done to increase the cache size and reduce the number of misses.
Included in the client RPC statistics are counts for various failures experienced while trying to send NFS requests to a server:
calls
Total number of calls made to all NFS servers.
badcalls
Number of RPC calls that returned an error. The two most common RPC failures are timeouts and interruptions, both of which increment the badcalls counter. The connection-oriented RPC statistics also increment the interrupts counter. There is no equivalent counter for connectionless RPC statistics. If a server reply is not received within the RPC timeout period, an RPC error occurs. If the RPC call is interrupted, as it may be if a filesystem is mounted with the intr option, then an RPC interrupt code is returned to the caller. nfsstat also reports the badcalls count in the NFS statistics. NFS call failures do not include RPC timeouts or interruptions, but do include other RPC failures such as authentication errors (which will be counted in both the NFS and RPC level statistics).
badxids
The number of bad XIDs. The XID in an NFS request is a serial number that uniquely identifies the request. When a request is retransmitted, it retains the same XID through the entire timeout and retransmission cycle. With the Solaris multithreaded kernel, it is possible for the NFS client to have several RPC requests outstanding at any time, to any number of NFS servers. When a response is received from an NFS server, the client matches the XID in the response to an RPC call in progress. If an XID is seen for which there is no active RPC call — because the client already received a response for that XID — then the client increments badxid. A high badxid count, therefore, indicates that the server is receiving some retransmitted requests, but is taking a long time to reply to all NFS requests. This scenario