The Network File System, NFS, was introduced by Sun Microsystems
Inc. in 1985. The goal was to provide transparent access to remote
file systems. Sun chose to make NFS an ``open'' protocol by
publishing the specification and by licensing a reference
installation. This has made NFS widely used and ported, to
non-Unix platforms as well. The first published version of NFS
was called Version 2 [Sun89]. In 1995, several vendors,
including Sun, IBM, and Digital, published an extended Version 3 of
the NFS protocol [PJS
94,CPS95].
NFS is a client/server protocol. An NFS server makes file systems available to clients. When attached to a server, a client application will perceive the file system exported by the server as being a part of its own local file system.
Figure 5.1 shows the principal components used in NFS client/server communications. Important pre-requisites for NFS are the Virtual File System (VFS) and the Remote Procedure Call mechanism (RPC). The VFS is an interface to an abstract file system and provides the indirection necessary in order to present a single file system to the client while physically there may actually be several. RPC, together with the External Data Representation standard (XDR), provides the network transport mechanism used by NFS. The VFS, RPC and XDR are all technologies introduced by Sun [Kle86,Sun87,Sun88].
Figure 5.1: NFS communications between two Unix computers
The operation where a client incorporates a remote file system into its own virtual file system is called mount. This initial exchange is specified in [Sun89] as a companion mount protocol to the NFS protocol. During the mount exchange the client receives an initial NFS file handle from the NFS server. The client passes a handle of this kind on every subsequent call to the NFS server. A file handle contains all information necessary for the server to carry out a request. This feature of the NFS protocol makes the server stateless as the server need not maintain any information about connected clients. This is a very important property of NFS as it makes the protocol very robust. For instance, there is no need for any special procedures to handle server crash recovery. If the server goes down, a client will simply retry its request until the server again comes online to serve it.
Once a client has mounted an NFS file system, the NFS
protocol specifies a number of functions a client may use to access the
server. In NFS version 2 there are 18 functions (of which one is
obsolete and one is for use in later versions), whereas in version 3
the number has been extended to 22. As our design is based on a
version 2 server
we discuss here only functions found in that
version.
Table 5.1: NFS version 2 requests
Table 5.1 summarizes the service functions defined in NFS version 2. Upon examination it is evident that the NFS services rather closely mirror file level operations available in a Unix system. However, by using a subset of the functions, or by providing suitable mappings, NFS has also been implemented for other operating systems, such as MS-DOS, Novell Netware and VMS (see for instance [Mic,Nov,Att]).