UNIX System Administration Handbook - Evi Nemeth [291]
Since NFS version 2 clients cannot assume that a write operation is complete until they receive an acknowledgment from the server, version 2 servers must commit each modified block to disk before replying, to avoid discrepancies in the event of a crash. This constraint introduces a significant delay in NFS writes, since modified blocks would normally be written only to the in-memory UNIX buffer cache.
NFS version 3 eliminates this bottleneck with a coherency scheme that makes writes safely asynchronous. It also updates several other aspects of the protocol that were found to have caused performance problems. The net result is that NFS version 3 is quite a bit faster than version 2.
Version 3 software is always capable of interoperating with version 2, although it simply falls back to using the earlier protocol.
Choice of transport
NFS runs on top of Sun’s RPC (Remote Procedure Call) protocol, which defines a system-independent way for processes to communicate over a network. One advantageous side effect of this architecture is that it’s possible to use either UDP or TCP as the underlying transport protocol.
NFS originally used UDP because that was what performed best on the LANs and computers of the 1980s. Although NFS does its own packet sequence reassembly and error checking, UDP and NFS both lack the congestion control algorithms that are essential for good performance on a large IP network.
To remedy these potential problems, most systems now allow you to use TCP as the transport for NFS instead of UDP. This option was first explored as a way to help NFS work through routers and over the Internet. However, the current consensus seems to be that TCP is usually the best option for local NFS traffic as well. Over time, most of the original reasons for preferring UDP over TCP have evaporated in the warm light of fast CPUs and cheap memory.
Servers that support TCP will generally accept connections on either transport, so the choice between TCP and UDP is made by the client. Most clients default to UDP; Solaris uses TCP.
TCP support was officially integrated into the NFS protocol specification in version 3. However, there are version 2 implementations out there that support TCP (such as Red Hat) and version 3 implementations that don’t (such as HP-UX).
Table 17.1 shows the support for TCP and NFS version 3 on our example systems. The Default column shows whether the client software defaults to using TCP or UDP.
Table 17.1 Advanced NFS feature support by OS
a. TCP is supported on the client side only.
WebNFS
In 1996, Sun launched an effort to promote the use of NFS on the Internet in a slightly tweaked form called WebNFS. A superset of the standard NFS version 3 protocol, WebNFS does away with (or more accurately, makes optional) several of the prefatory transactions that traditional NFS clients must go through before accessing a filesystem. It’s not intended to replace traditional NFS, but rather to support applets running within web browsers. Unless your organization is involved in writing such applets, WebNFS will probably not be of much interest to you.
As of this writing, all of our example operating systems except HP-UX provide server-side support for WebNFS. You can find out more at www.sun.com/webnfs.
File locking
File locking (as provided by the flock and/or lockf systems calls) has been a sore point on UNIX systems for a long time. On local filesystems, it has been known to work less than perfectly. In the context of NFS, the ground is shakier still. By design, NFS servers are stateless: they have no idea which machines are using any given file. However, this information is needed to implement locking. What to do?
The traditional answer has been to implement file locking separately from NFS. Most systems provide two daemons, lockd and statd, that try to make a go of it. Unfortunately, the task is difficult