Managing NFS and NIS, 2nd Edition - Mike Eisler [264]
You can also reduce NFS traffic by increasing the attribute timeout (actimeo) specified at mount time. As explained in Section 7.4.1, NFS clients cache file attributes to avoid having to go to the NFS server for information that does not change frequently. These attributes are aged to ensure the client will obtain refreshed attributes from the server in order to detect when files change. These "attribute checks" can cause a significant amount of traffic on a WAN. If you know that your files do not change frequently, or you are the only one accessing them (they are only changed from your side of the WAN), then you can increase the attribute timeout in order to reduce the number of "attribute refreshes."
Over a long-haul network, particularly one that is run over modem or ISDN lines, you will want to make sure that UDP checksums are enabled. Solaris has UDP checksums enabled by default, but not all operating systems use them because they add to the cost of sending and receiving a packet. However, if packets are damaged in transit over the modem line, UDP checksums allow you to reject bad data in NFS requests. NFS requests containing UDP checksum errors are rejected on the server, and will be retransmitted by the client. Without the checksums, it's possible to corrupt data.
You need to enable the checksums on both the client and server, so that the client generates the checksums and the server verifies them. Check your vendor's documentation to be sure that UDP checksums are supported; the checksum generation is not always available in older releases of some operating systems.
NFS async thread tuning
Early NFS client implementations provided biod user-level daemons in order to add concurrency to NFS operations. In such implementations, a client process performing an I/O operation on a file hands the request to the biod daemon, and proceeds with its work without blocking. The process doesn't have to wait for the I/O request to be sent and acknowledged by the server, because the biod daemon is responsible for issuing the appropriate NFS operation request to the server and to wait for its response. When the response is received, the biod daemon is free to handle a new I/O request. The idea is to have as many concurrent outstanding NFS operations as the server can handle at once, in order to accelerate I/O handling. Once all biod daemons are busy handling I/O requests, the client-side process generating the requests has to directly contact the NFS server and block awaiting its response.
For example, a file read request generated by the client-side process is handed to one biod daemon, and the rest of the biod daemons are asked to perform read-ahead operations on the same file. The idea is to anticipate the next move of the client-side application, by assuming that it is interested in sequentially reading the file. The NFS client hopes to avoid having to contact the NFS server on the next I/O request by the application, by having the next chunk of data already available.
Solaris, as well as other modern Unix kernels support multiple threads of execution without the need of a user context. Solaris has no biod daemons, instead it uses kernel threads to implement read-ahead and write-behind, achieving the same increased read and write throughput.
The number of read-aheads performed once the Solaris client detects a sequential read pattern is specified by the kernel tunable variables nfs_nra for NFS Version 2 and nfs3_nra for NFS Version 3. Solaris sets both values to four read-aheads by default. Depending on your file access