Managing NFS and NIS, 2nd Edition - Mike Eisler [223]
zeus# cat /var/nfs/logs/nfslog
Mon Jul 31 11:35:08 2000 0 rome 65536 /export/home/64k-file b _ i r 19069 nfs 0 *
Mon Jul 31 11:35:25 2000 0 rome 131072 /export/home/128k-file b _ o r 19069 nfs 0 *
The nfslogd daemon
It is the nfslogd daemon that generates the ultimate NFS log file. The daemon periodically wakes up to process the contents of the work buffer file created by the kernel, performs hostname and pathname mappings, and generates the file transfer log record. Since the filesystem can be reshared with logging disabled, or simply be unshared, the nfslogd daemon cannot rely on the list of exported filesystems to locate the work buffer files. So how exactly does the nfslogd daemon locate the work buffer files?
When a filesystem is exported with logging enabled, the share command adds a record to the /etc/nfs/nfslogtab file indicating the location of the work buffer file, the filesystem shared, the tag used to share the filesystem, and a 1 to indicate that the filesystem is currently exported with logging enabled. This system table is used to keep track of the location of the work buffer files so they can be processed at a later time, even after the filesystem is unshared, or the server is rebooted. The nfslogd daemon uses this system file to find the location of the next work buffer file that needs to be processed. The daemon removes the /etc/nfs/nfslogtab entry for the work buffer file after processing if the corresponding filesystem is no longer exported. The entry will not be removed if the filesystem remains exported.
The nfslogd daemon removes the work buffer file once it has processed the information. The kernel creates a new work buffer file when more RPC requests arrive. To be exact, the work buffer file currently accessed by the kernel has the _in_process string appended to its name (name specified by the buffer parameter in /etc/nfs/nfslog.conf ). The daemon, asks the kernel to rename the buffer to the name specified in the configuration file once it is ready to process it. At this point the kernel will again create a new buffer file with the string appended and start writing to the new file. This means that the kernel and the nfslogd daemon are always working on their own work buffer file, without stepping on each others' toes. The nfslogd daemon will remove the work buffer file once it has processed the information.
You will notice that log records do not show up immediately on the log after a client accesses the file or directory on the server. This occurs because the nfslogd daemon waits for enough RPC information to gather in the work buffer before it can process it. By default it will wait five minutes. This time can be shortened or lengthened by tuning the value of IDLE_TIME in /etc/default/nfslogd.
Consolidating file transfer information
The NFS protocol was not designed to be a file transfer protocol, instead it was designed to be a file access protocol. NFS file operations map nicely to Unix filesystem calls and as such, its file data access and modification mechanisms operate on regions of files. This enables NFS to minimize the amount of data transfer required between server and client, when only small portions of the file are needed. The NFS protocol enables reads and writes of arbitrary number of bytes at any given offset, in any given order. NFS clients are not required to read a file on an NFS server in any given order, they may start in the middle and read an arbitrary number of bytes at any given offset.
The random byte access, added to the fact that NFS Versions 2 and 3 do not define an open or close operation, make it hard to determine when an NFS client is done reading or writing a file. Despite this limitation, the nfslogd daemon does a decent job identifying file transfers by using various heuristics to determine when to generate the file transfer record.
Filehandle to path mapping
Most NFS operations take a filehandle as an argument, or return a filehandle as a result of the operation. In the NFS protocol,