Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Network file system by Waqas

Published in: Education, Technology
  • Be the first to comment


  1. 1. Network File System (NFS) CS454/554 Department of Computer Science Iowa State University
  2. 2. Introduction <ul><li>Sun Microsystems, Inc. defined a remote file access mechanism that has become widely accepted throughout the computer industry, known as NFS. </li></ul><ul><li>The mechanism allows a computer to run a server that makes some or all of its files available for remote access, and allow applications on other computers to access those files. </li></ul>
  3. 3. Remote File Access Vs Transfer <ul><li>When an application accesses a file that resides on a remote machine, the program’s operating system invokes client software that contacts a file server on the remote machine and performs the requested operations on the file. </li></ul><ul><li>Unlike a file transfer, the application’s system does not retrieve or store an entire file at once; instead, it requests transfer of one small block of data at a time. </li></ul>
  4. 4. File Access Among Heterogeneous Computers <ul><li>In addition to the basic mechanisms for reading file protections, and translate information among the presentations used on various computers. </li></ul><ul><li>Because a remote file access service connects two machines, it must handle differences in the way the client and server systems name files, denote paths through directories, and store information about files. </li></ul><ul><li>The files access software must accommodate differences and writing files, a file access service must provide ways to create and destroy files, peruse directories, authenticates requests, honor in the semantics interpretation of file operations. </li></ul>
  5. 5. Stateless Servers <ul><li>The NFS design stores state information at the client site, allowing servers to remain stateless. </li></ul><ul><li>Because the server is stateless, disruption in service will not affect client operation. </li></ul><ul><li>A client will be able to continue file access after a stateless server crashes and reboots; the application program, which runs on the client system, can remain unaware of the server reboot. </li></ul><ul><li>Because a stateless server does not need to allocate resources for each client, a stateless design can scale to handle more clients than a stateful design. </li></ul>
  6. 6. NFS and UNIX File Semantics <ul><li>The NFS designers adopted UNIX file system semantics when defining the meaning of individual operations. </li></ul><ul><li>Understanding the UNIX file system is essential to understanding NFS because NFS uses the UNIX file systems terminologies and semantics. </li></ul><ul><li>It honors the same open-read-write-close paradigm as UNIX, and offers most of the same services. </li></ul><ul><li>Like UNIX, NFS assumes a hierarchical naming system. It considers the file hierarchy to be composed of directories and files. </li></ul>
  7. 7. NFS File Types <ul><li>enum ftype { </li></ul><ul><li>NFNON = 0, /*specified name is not a file */ </li></ul><ul><li>NFREG = 1, /* regular file */ </li></ul><ul><li>NFDIR = 2, /* directory */ </li></ul><ul><li>NFBLK = 3, /* block-oriented device */ </li></ul><ul><li>NFCHR = 4, /* character-oriented device */ </li></ul><ul><li>NFLNK = 5 /* symbolic link */ </li></ul><ul><li>}; </li></ul><ul><li>NFS has adopted UNIX’s terminology that divides I/O devices into block-oriented (a disk device) and character-oriented (a terminal device) devices. </li></ul>
  8. 8. NFS File Modes <ul><li>NFS assumes that file or directory has a mode that specifies its type and access protection. </li></ul><ul><li>The definitions and meaning of bits in the NFS mode integer is very similar to that of UNIX. </li></ul><ul><li>Although NFS defines file types for devices, it does not permit remote device access (e.g., a client may not read or write a remote device) </li></ul>
  9. 9. NFS Client and Server <ul><li>An NFS file server runs on a machine (which has large disks) that has a local file system. </li></ul><ul><li>An NFS client runs on an arbitrary machine and access the files on machines that run NFS servers. </li></ul><ul><li>When an application program calls open to obtain access to a file, the OS uses the syntax of the path name to choose between local and remote file access procedures. </li></ul><ul><li>If the path refers to a local file, the system uses the computer’s standard file system software to access the file; If the path refers to a remote file, the system uses NFS client software to access the remote file. </li></ul>
  10. 10. NFS Client and UNIX <ul><li>In UNIX, the mount mechanism construct a single, unified naming hierarchy from individual file systems on multiple disks. </li></ul><ul><li>UNIX implementation of NFS client code use an extended version of the mount mechanism to integrate remote file systems into the naming hierarchy along with local file systems. </li></ul><ul><li>The chief advantage of using the mount mechanism is consistency : all file names have the same form. </li></ul><ul><li>An application program cannot tell whether a file is local or remote from the name syntax alone. </li></ul>
  11. 11. <ul><li>When an application opens a remote file, it receive an integer descriptor for the file exactly as it would for a local file. </li></ul><ul><li>Internal information associated with the descriptor specifies that the file is a remote file accessible through NFS. </li></ul><ul><li>Whenever an application performs an operation on a file descriptor, the system checks to see whether the descriptor refers to a local or a remote file. If local, the OS handles the operation as usual, else, the OS calls NFS client translates the operation into an equivalent NFS operation and places a RPC call to the server. </li></ul>
  12. 12. NFS Client Operation <ul><li>The path name syntax used by the remote file system may differ from that of the client machine; e.g. NFS client code on Windows 95 (uses blackslash () as a separator character), while NFS server code on UNIX (uses slash (/) as a separator character). </li></ul><ul><li>To keep applications on client machines independent of file locations and server computer systems, NFS requires that only clients interpret full path names. </li></ul><ul><li>A client traces a path through the server’s hierarchy by sending the server one component at a time and receiving information about the file or directory it names. </li></ul><ul><li>For example, look up path name /a/b/c on a server, it begins by obtaining information about the server’s root directory, then look up name a in that directory, then look up name b in that directory a, then look up name c in b. </li></ul>
  13. 13. File Handle <ul><li>In order to isolate clients from the server’s path name syntax and to allow heterogeneous machines to access hierarchical files, NFS requires that the client perform all path name interpretation. </li></ul><ul><li>As a consequence, a client can not use a full path name to specify a file when requesting an operation on that file. </li></ul><ul><li>Instead, the client must obtain a handle that it can use to reference the file. </li></ul><ul><li>Having the server provide handles for directories as well as files permits a client to trace a path through the server’s hierarchy. </li></ul>
  14. 14. An NFS Client in UNIX <ul><li>When managers install NFS client code in UNIX, they use the file system mount facility to integrate remote directories into UNIX’s hierarchical directory system. </li></ul><ul><li>The manager creates an empty directory in the existing system, and then mounts an NFS remote file system on it. Whenever an application program calls open, the system parses the path name one component at a time. </li></ul><ul><li>It looks up each component in a directory and finds the next directory to search. </li></ul>
  15. 15. <ul><li>If the path specified in a call to open includes an NFS-mounted directory, the system will eventually encounter the remote mount point and pass control to the NFS client code. </li></ul><ul><li>The NFS client finishes opening the file by continuing to parse and look up components of the path. </li></ul><ul><li>Because the remaining directories in the path reside on a remote machine, the NFS client code look up each component by contacting the appropriate NFS server and obtain handle for the remote file for subsequent read and write operations. </li></ul>
  16. 16. File Positioning with A Stateless Server <ul><li>Because NFS uses a stateless server design, the client stores all file position information and each request sent to the server must specify the file position to use. </li></ul><ul><li>In UNIX implementation, NFS uses the local file table to store the position for a remote file just as UNIX uses it to store position in a local file. </li></ul><ul><li>If the client calls lseek , the system records the new file position in the table without sending a message to the server. </li></ul><ul><li>Any subsequent access operation extracts the file position from the table and sends it to the server along with the access request. </li></ul>
  17. 17. Reading a Directory Statelessly <ul><li>Because directories can be arbitrarily large and communication networks impose a fixed limit on the size of a single message, reading the contents of a directory may require multiple requests. </li></ul><ul><li>Because NFS servers are stateless, the server cannot keep a record of each client’s position in the directory. </li></ul><ul><li>To overcome this limitation, NFS server returns a position identifier when it answers a request for an entry from a directory. </li></ul>
  18. 18. <ul><li>The client use the position identifier in the next request to specify which entries it has already received and which it still needs, i.e. it steps through the directory by making repeated that each specify the position identifier returned in the previous request. </li></ul><ul><li>NFS calls its directory position identifier a magic cookie , implying that the client does not interpret the identifier, nor can it fabricate an identifier itself. </li></ul><ul><li>Only a server can create a magic cookie and a client can only use a magic cookie that has been supplied by a server. </li></ul>
  19. 19. The Mount Protocol <ul><li>The mount protocol provides four basic services that clients need before they can use NFS: </li></ul><ul><ul><li>It allows the client to obtain a list of the directory hierarchies (i.e. the file systems) that the client can access through NFS. </li></ul></ul><ul><ul><li>It accepts full path names That allow the client to identify a particular directory hierarchy. </li></ul></ul><ul><ul><li>It authenticates each client’s request and validates the client’s permission to access the requested hierarchy. </li></ul></ul><ul><ul><li>It returns a file handle for the root directory of the hierarchy a client specifies. </li></ul></ul><ul><li>The client uses the root handle obtained from the mount protocol when making NFS calls. </li></ul>
  20. 20. Summary <ul><li>To allow many clients to access a server and to keep the servers isolated from client crashes, NFS uses stateless servers. </li></ul><ul><li>To accommodate heterogeneity, NFS requires the client to parse path names and look up each component individually and the server returns a 32-bytes handle. </li></ul><ul><li>NFS adopted the open-read-write-close paradigm used in UNIX, along with basic file types and file protection modes. </li></ul>