You are on page 1of 6

Aim: Study of Distributed File System - Network File System and Coda.

NFS PROTOCOL DEFINITION : Servers change over time, and so can the protocol that they use. RPC provides a version number with each RPC request. This RFC describes version two of the NFS protocol. Even in the second version, there are a few obsolete procedures and parameters, which will be removed in later versions. An RFC for version three of the NFS protocol is currently under preparation. NFS Overview: The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update file on a remote computer as though they were on the user's own computer. The user's system needs to have an NFS client and the other computer needs the NFS server. Both of them require that you also have TCP/IP installed since the NFS server and client use TCP/IP as the program that sends the files and updates back and forth. (However, the User Datagram Protocol, UDP, which comes with TCP/IP, is used instead of TCP with earlier versions of NFS.) NFS was developed by Sun Microsystems and has been designated a file server standard. Its protocol uses the Remote Procedure Call (RPC) method of communication between computers. You can install NFS on Windows 95 and some other operating systems using products like Sun's Solstice Network Client. Using NFS, the user or a system administrator can mount all or a portion of a file system (which is a portion of the hierarchical tree in any file directory and subdirectory, including the one you find on your PC or Mac). The portion of your file system that is mounted (designated as accessible) can be accessed with whatever privileges go with your access to each file (read-only or read-write). NFS has been extended to the Internet with WebNFS, a product and proposed standard that is now part of Netscape's Communicator browser. WebNFS offers what Sun believes is a faster way to access Web pages and other Internet files The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update file on a remote computer as though they were on the user's own computer. The user's system needs to have an NFS client and the other computer needs the NFS server. Both of them require that you also have TCP/IP installed since the NFS server and client use TCP/IP as the program that sends the files and updates back and forth. (However, the

WebNFS offers what Sun believes is a faster way to access Web pages and other Internet files Diagram: . UDP. Using NFS. You can install NFS on Windows 95 and some other operating systems using products like Sun's Solstice Network Client. Its protocol uses the Remote Procedure Call (RPC) method of communication between computers. a product and proposed standard that is now part of Netscape's Communicator browser. the user or a system administrator can mount all or a portion of a file system (which is a portion of the hierarchical tree in any file directory and s ubdirectory. is used instead of TCP with earlier versions of NFS.) NFS was developed by Sun Microsystems and has been designated a file server standard. The portion of your file system that is mounted (designated as accessible) can be accessed with whatever privileges go with your access to each file (read-only or read-write). including the one you find on your PC or Mac).User Datagram Protocol. which comes with TCP/IP. NFS has been extended to the Internet with WebNFS.

The server has to be running the following daemons: Daemon nfsd mountd rpcbind Description The NFS daemon which services requests from the NFS clients. device. The nfsiod daemon services the requests from the NFS server. In order for this to function properly a few processes have to be configured and running. NFS Implementation Issues. Different operating systems may have restrictions on the depth of the tree or the names used.NFS Working NFS consists of at least two main parts: a server and one or more clients. pathnames need separators between the directory components. First. different procedures are used to read directories and files. The same argument as above could have been used to justify a procedure that returns only one directory entry per call. Version 3 of NFS uses slightly more general file system model. but is not required for normal and correct operation. It may not be obvious why it does not just take the whole pathname. Some operating systems provide a "mount" operation to make all file systems appear as a single tree. with directories as all but the bottom level of files. and a remote call to return each would be just too slow. . This provides a network standard format for representing directories. There are several good reasons not to do this. traipse down the directories. directory. as well as using different syntax to represent the "pathname". This is optional. The client remotely accesses the data that is stored on the server machine. File System Model NFS assumes a file system that is hierarchical. while others maintain a "forest" of file systems. Other issues are discussed in section 3. The client can also run a daemon. and different operating systems use different separators. This daemon allows NFS clients to discover which port the NFS server is using. The NFS mount daemon which carries out the requests that nfsd(8) passes on to it. Although files and directories are similar objects in many ways. Directories can contain many entries. A "file system" is a tree on a single server (usually a single disk or physical partition) with a specified "root". and improves performance. which is the concatenation of all the "components" (directory and file names) in the name. and return a file handle when it is done. The problem is efficiency. known as nfsiod. Files are unstructured streams of uninterpreted bytes.) has a string name. We could define a Network Standard Pathname Representation. Each entry in a directory (file. NFS looks up one component of a pathname at a time. but then every pathname would have to be parsed and converted at each end. etc.

there is a separate Virtual File System (VFS) layer that intercepts all calls from client appli. as shown in Fig. the designers of Coda have also tried to reach a high degree of failure transparency. in turn. Overview of Coda Coda was designed to be a scalable. An important goal was to achieve a high degree of naming and location transparency so that the system would appear to its users very similar to a pure local file system. A Venus process is responsible for providing access to the files that are maintained by the Vice file servers. The internal architecture of a Virtue workstation is shown in Fig. Overviews of Coda are described in (Satyanarayanan et al.THE CODA FILE SYSTEM Our next example of a distributed file system is Coda.. Venus is also responsible for allowing the client to continue operation even if access to the file servers is (temporarily) impossible. whose role is similar to that of an NFS client. Every Virtue workstation hosts a user-level process called Venus. This organization with VFS is the same as in NFS. 1996). Venus. Processes Coda maintains a clear distinction between client and server processes. The RPC system is constructed on top of UDP datagrams and provides at-most-once semantics. and is now integrated with a number of popular UNIX-based operating systems such as Linux. 1990. This additional role is a major difference with the approach followed in NFS. servers appear as Vice processes. Both type of processes are internally organized as a collection of concurrent threads. A detailed description of the system can be found in (Kistler. Coda follows the same organization as AFS. Kistler and Satyanarayanan. secure. 1992). The important issue is that Venus runs as a user-level process. a separate thread is used to handle all I/O operations. By also taking high availability into account. and highly available distributed file system. 10-2. Clients are represented by Venus processes. Coda is in many ways different from NFS. and forwards these calls either to the local file system or to Venus. which it implements using low-level asynchronous I/O operations of the underlying operating system. Communication . Threads in Coda are nonpreemptive and operate entirely in user space. communicates with Vice file servers using a user-level RPC system. Coda has been developed at Carnegie Mellon University (CMU) in the 1990s.cations. Again. 10-2. To account for continuous operation in the face of blocking I/O requests. notably with respect to its goal for high availability. This goal has led to advanced caching schemes that allow a client to continue operation despite being disconnected from a server. In Coda. This thread effectively emulates synchronous I/O without blocking an entire process.

the server regularly sends back messages to the client to let it know it is still working on the request. an actual file system). Connection setup is done as a side effect of an RPC call to the server. Like disk partitions. Usually a volume corresponds to a collection of files associated with a user. As request processing may take an arbitrary time to complete. the RPC2 client code starts a new thread that sends an invocation request to the server and subsequently blocks until it receives an answer. Examples of volumes include collections of shared binary or source files. RPC2 offers reliable RPCs on top of the (unreliable) UDP protocol.e. For this purpose. For example. These routines are automatically called by the RPC2 runtime system at the client and server. there are routines for setting up a connection and routines for transferring data. It corresponds to a partial subtree in the shared name space as maintained by the Vice servers. RPC2 allows the client and the server to set up a separate connection for transferring the video data to the client on time. volumes can be . Coda maintains a naming system analogous to that of UNIX.tion is otherwise completely independent of RPC2 Naming As we mentioned. the RPC2 runtime system provides an interface of side-effect routines that is to be implemented by the application developer. and so on. respectively. which is used by NFS. Each time a remote procedure is called. but generally has a much smal. but their implementa. However.Interprocess communication in Coda is performed using RPCs.ler granularity. the RPC2 system for Coda is much more sophisticated than traditional RPC systems such as ONC RPC. Files are grouped into units referred to as volumes. If the server dies. A volume is similar to a UNIX disk partition (i.. sooner or later this thread will notice that the messages have ceased and report back failure to the calling application.

An interesting aspect of Coda that needs further explanation is how a client can continue to operate while being disconnected.mounted. which is mainly reflected by its sophisticated support for client-side caching and its support for server replication. Fault Tolerance Coda has been designed for high availability. even if disconnection lasts for hours or days. Conclusion:. A mount point in Coda is a leaf node of a volume that refers to the root node of another volume. Volumes are important for two reasons. This construction takes place by mounting volumes at mount points. they form the basic unit by which the entire name space is constructed. We have discussed both in the preceding sections. First.Hence we have studied NFS and CODA .