The Sun Network File System
 ===========================

 Summary:  SUN NFS is described. It is a remote file system, designed
     to be portable across operating systems and architectures.

 Design Goals:

     - Machine and OS independance
     - Fast crash recovery
     - Transparent access to files
     - UNIX semantics on UNIX clients
     - Reasonable performance

 Design Details:

     - Uses XDR for machine/network independant data format.

     - Uses Sun RPC, which is transport layer independant.

     - Defines NFS protocol. It is a set of (RPC) procedures, their
       arguments, results and effects, e.g. lookup(), create() etc.
       The protocol is stateless and idempotent.  Each RPC is a
       "transaction" by itself. Also, it allows transparent access
       to files, once the file system has been mounted.

     - The statelessness of NFS protocol requires the server to
       commit all changes (i.e., all modified data need be flushed to
       disk) before returning a procedure call.
       Each procedure call contains all the parameters required, and
       is independant of previous calls. No client state is maintained at
       the  server.

     - The statelessness of NFS makes recovery very simple. The server
       just boots and resumes file operations!  The client simply retries
       a procedure call if it times out.  It cannot distinguish
       between a server that crashed and recovered, and a slow server.

     - In order to make NFS transparent to user programs, the inode
       concept was abstracted into a VFS/Vnode interface which allows
       new file system implementations to be "plugged in" easily. It
       also allows for multiple file system types, with a common
       directory hierarchy.

     - A remote file system has to be "mounted" by clients.
       An RPC-based mount server authenticates and manages mounts by
       clients. Once a file system has been mounted, path name traversal
       is done at the client side.

     - An RPC-based YP service makes distribution and central
       administration of system databases easier.  It provides network
       wide authentication of clients.

     - An RPC-based locking service called the status monitor keeps
       tracks of machines on the network so that resources corresponding
       to a crashed machine can be freed.

     - The paper also differentiates NFS from RFS, pointing out
       shortcomings in RFS.  The strengths of NFS are: (a) Transport
       layer independant, (b) Open standards, (c) Support for heterogenous
       machines and OS's, (d) Fast crash recovery, and (e) Easier
       administration via yp service.

 Problems:

     - Grossly inadequate solution for concurrent access to remote files.
       e.g., Long writes => multiple RPC's.  Two long writes from
       different could be interleaved as atomicity is at a procedure call
       level.

       How much file sharing takes place in workstation environments?

     - Time skew. Client and server could have different clocks.
       This warrants a time synchronization protocol (NTP?).

     - Performance?