18.4. NFS over wide-area networks

NFS over wide-area networks (WANs) greatly benefits when it is run over the TCP transport. NFS over TCP is preferred when the traffic runs over error-prone or lossy networks. In addition, the reliable nature of TCP allows NFS to transmit larger packets over this type of network with fewer retransmissions.

Although NFS over TCP is recommended for use over WANs, you may have to run NFS over UDP across the WAN if either your client or server does not support NFS over TCP. When running NFS over UDP across WANs, you must adjust the buffer sizes and timeouts manually to account for the differences between the wide-area and the local-area network. Decrease the rsize and wsize to match the MTU of the slowest wide-area link you traverse with the mount. While this greatly increases the number of RPC requests that are needed to move a given part of a file, it is the most social approach to running NFS over a WAN.

If you use the default 32KB NFS Version 3 buffer, you send long trains of maximum sized packets over the wide-area link. Your NFS requests will be competing for bandwidth with other, interactive users' packets, and the NFS packet trains are likely to crowd the rlogin and telnet packets. Sending a 32 KB buffer over a 128 kbps ISDN line takes about two seconds. Writing a small file ties up the WAN link for several seconds, potentially infuriating interactive users who do not get keyboard echo during that time. Reducing the NFS buffer size forces your NFS client to wait for replies after each short burst of packets, giving bandwidth back to other WAN users.

In addition to decreasing the buffer size, increase the RPC timeout values to account for the significant increase in packet transmission time. Over a wide-area network, the network transmission delay will be comparable (if not larger) to the RPC service time on the NFS server. Set your timeout values based on the average time required to send or receive a complete NFS buffer. Increase your NFS RPC timeout to at least several seconds to avoid retransmitting requests and further loading the wide-area network link.

You can also reduce NFS traffic by increasing the attribute timeout (actimeo) specified at mount time. As explained in Section 7.4.1, "File attribute caching", 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.

---