Chapter 29

p. 461

The chapter largely describes NFS version 2 (RFC 1094). Version 3 is described in RFC 1813 and version 4 in RFC 3010⁵⁷.

p. 462, second (3)

Technically speaking, it is not the RPC mechanism (RFC 1057) which handles the data translation, but XDR (RFC 1014) or an equivalent. However, all RPC packages actually implement both.

p. 469

Although NFS file handles are meant to be opaque, some implementations had clients which did look at the contents of the file handle. This caused serious compatibility problems when the clients and servers were from different vendors, with different layouts of the file handle⁵⁸.

p. 469

However, in WebNFS⁵⁹, there is a concept of a ``public file handle'', described as follows.

It is an NFS filehandle with a reserved value and special semantics that allow an initial filehandle to be obtained. A WebNFS client can use the public filehandle as an initial filehandle rather than using the MOUNT protocol.

It is an all-zero file handle: more precisely 32 bytes of zero in NFS v2 and a handle with a length of zero in NFS v3.

Incidentally, we should note that the last line of this page should read increases with version 3 to a maximum of 64 bytes -- NFS v3 file handles have a length field.

p. 469

The generation number exists to deal with the following problem.

Client:

Opens file fred for reading, gets back a file handle with i-node 9999.

Server:

Removes file fred, and the i-node is free for re-use.

Server/Client:

Creates file joe, to which the server allocates i-node 9999.

Client:

Reads from the file-handle obtained above, thinking it is reading from fred, but in fact reading from joe (the NFS read protocol only talks in terms of file handles, not names).

With generation numbers, the fourth step would fail, since there would be a mismatch of generation numbers in the file handle, and the client would print the error message ``stale NFS file handle''.

In practice, at step 2 the server tries to check (using the locking mechanism) whether fred is in use on the client, and, if so, renames it as .nfs9999 in order to keep the contents around, and preserve the i-node.

NFS is not perfect, however. If two clients⁶⁰ $C_1$ and $C_2$ are accessing the same files on a server $S$, say in the order $C_1$, $C_2$, $C_1$, with each access being of the form ``read the file, then write it'', and the different clients not overlapping (if they did overlap, then the lock manager should intervene), then what may happen is that $C_1$'s second access may not see $C_2$'s changes, since the old $C_1$ data are still in $C_1$'s cache. Even running sync on $C_1$ (assuming $C_1$ is a Unix machine) will not help, since this will merely double-check that the data have been sent to $S$, but will not invalidate $C_1$'s cache. Fundamentally, most file systems pre-date NFS in their design, even though they have been patched since.

p. 473

Although NFS traditionally used UDP, there are great advantages in using TCP when there is any possibility of packet loss: the fixed (and large) time-outs in RPC over UDP are no match for the sophisticated RTT calculations in TCP. ``For example, a 1% packet loss rate on a 10MHz Ethernet with classic default NFS/UDP/IP timeouts causes a 90% loss of throughput using 8 KByte buffer sizes and no more read-ahead than done by classic UFS style file systems.''⁶¹