Read Design and Implementation of the Sun Network Filesystem, by Sandberg, Goldberg, Kleiman, Walsh, and Lyon (reading #10). Read only the first five pages (up to the Implementation section).

NFS provides a filesystem interface to files stored on a remote machine. You are familiar with another network file system, AFS, which provides the same functionality to you when you login to an Athena workstation and access your home directory. This paper touches on networking issues that we have been discussing for the past several weeks and also serves as an introduction to the problems of naming and reliability. We will begin discussing naming in lecture this week and reliability later in the term. We'll consider a few questions from each topic area in this guide.

Consider NFS's use of the network. NFS uses UDP as its transport instead of TCP. If you aren't familiar with UDP, you can think of it as a very thin wrapper around IP that provides demultiplexing to multiple applications on a single machine. Why didn't the NFS designers choose TCP instead? NFS clients and servers use synchronous RPCs to exchange information. If you recall the X-windows paper, the authors of that system chose to use asynchronous RPC to hide network latency. How is it that NFS can use synchronous RPC and still obtain high performance? A partial answer to this question can be found on page 128 of the paper. Pay close attention to the timers used by NFS to retransmit lost or delayed RPCs. Does this retransmission scheme provide any sort of flow control? What do you think will happen to the throughput of an NFS server as the load is increased beyond the server's capacity?

NFS raises a number of interesting naming questions. NFS goes to great lengths to make sure file handles are unique; it adds generation numbers for inodes and a file system ID to the filehandle in addition to the inode number. What is it about NFS's design that makes unique filehandles so important? What could go wrong if two files had the same filehandle? Can the server (as it is designed) prevent this error? The architects of NFS modified the UNIX kernel significantly to add the Virtual File System interface; modern Unices retain the VFS even when they don't use NFS. VFS provides a layer of indirection between applications and the underlying file system. Why was this indirection so important to NFS?

The paper claims that NFS operations are idempotent. Idempotent operations can be safely executed more than once. Look at the table on page 121 and consider how NFS operations were crafted to make them idempotent. In particular, compare the NFS write to the standard UNIX write system call. Why is the UNIX syscall not idempotent? Can the rename NFS operation be considered idempotent? What about if there are multiple clients? What do the NFS authors really mean when the say NFS operations are idempotent?