Managing NFS and NIS, 2nd Edition - Mike Eisler [217]
* * *
[1] According to Leendert's web page, the tool has not been updated in recent years, although he still plans to get to it at some point.
Version 2 and Version 3 differences
NFS Version 2 and NFS Version 3 are entirely separate protocols and should be treated as such. The two protocols define different over-the-wire operations. For example, a single over-the-wire NFS Version 3 operation may correspond to several over-the-wire NFS Version 2 operations. Consider the case of a long list (ls -l ) of an NFS-mounted directory that generates a series of readdir/lookup/getattr NFS Version 2 calls. The same operation generates one or more readdir+ NFS Version 3 calls instead.
In general, NFS Version 3 attempts to reduce the number of over-the-wire requests by placing more information into each RPC. This makes NFS Version 3 more efficient under certain circumstances but less under others. The important point here is to understand that it is not possible to compare many of the NFS operations between the two protocols.
For example, writing a several megabyte file over NFS Version 3 will generate far fewer RPC write operations than the same file written over NFS Version 2. This is because NFS Version 3 writes generated by current Solaris clients are 32 KB in length.[2] In contrast, NFS Version 2 writes can only be up to 8 KB. You should be careful not to assume that NFS Version 2 writes are faster only because nfsstat -c reports that the server handles more of them.
You may also notice that NFS Version 3 generates fewer lookup and getattr operations than NFS Version 2. The reduction in lookups in NFS Version 3 is partly due to the use of readdir+, which includes the filehandle of the directory entries along with the directory names. The reduction of getattrs is mostly due to the fact that NFS Version 3 operations include post-operation attributes in all replies.
* * *
[2] The NFS Version 3 protocol does not impose a size limit on the write request. The fact that many NFSVersion 3 clients use 32 KB is an implementation detail.
NFS server logging
Solaris 8 introduces the new NFS Server Logging utility. This utility enables the system to log file transfer operations between an NFS server and any of its clients. This utility was created to provide logging facilities to sites that publish their archives via NFS within the intranet, and via WebNFS over the Internet.
The NFS Server Logging utility provides the system administrator with the tools to track file downloads and uploads, as well as directory modification operations on NFS exported filesystems. Be careful not to confuse this functionality with UFS Logging.[3]
The NFS Server Logging utility is not intended to serve as a debugging tool that can be turned on to peek at filesystem traffic during a short period of time and then be turned back off. NFS Server Logging is most useful when it is enabled before the filesystem is shared for the first time, and remains enabled the entire time the filesystem is exported. It needs to run continuously in order to monitor all NFS filesystem activity on the server, otherwise, important path mapping information may not be obtained. This is discussed in more detail in Section 14.6.5.
This utility provides functionality different from that provided by the public domain tools previously discussed. These tools generate records of individual RPC transactions, whereas NFS Server Logging generates records of conceptual file operations. Network sniffer tools like Ethereal and snoop report a file copy as a sequence of distinct NFS read operations of certain length and offset performed by the client. In contrast, the NFS Server Logging utility generates a single record specifying the total transfer size and the duration of the transfer. The NFS Server Logging utility reports accesses at the conceptual level (file uploads or downloads), where network sniffers report the details of the RPC and NFS operations. Consequently, the logs generated by the NFS Server Logging utility are orders of magnitude