rfc1094.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,515 行 · 第 1/4 页

Network Working Group                             Sun Microsystems, Inc.
Request for Comments: 1094                                    March 1989


            NFS: Network File System Protocol Specification

STATUS OF THIS MEMO

   This RFC describes a protocol that Sun Microsystems, Inc., and others
   are using.  A new version of the protocol is under development, but
   others may benefit from the descriptions of the current protocol, and
   discussion of some of the design issues.  Distribution of this memo
   is unlimited.

1. INTRODUCTION

   The Sun Network Filesystem (NFS) protocol provides transparent remote
   access to shared files across networks.  The NFS protocol is designed
   to be portable across different machines, operating systems, network
   architectures, and transport protocols.  This portability is achieved
   through the use of Remote Procedure Call (RPC) primitives built on
   top of an eXternal Data Representation (XDR).  Implementations
   already exist for a variety of machines, from personal computers to
   supercomputers.

   The supporting mount protocol allows the server to hand out remote
   access privileges to a restricted set of clients.  It performs the
   operating system-specific functions that allow, for example, to
   attach remote directory trees to some local file system.

1.1.  Remote Procedure Call

   Sun's Remote Procedure Call specification provides a procedure-
   oriented interface to remote services.  Each server supplies a
   "program" that is a set of procedures.  NFS is one such program.  The
   combination of host address, program number, and procedure number
   specifies one remote procedure.  A goal of NFS was to not require any
   specific level of reliability from its lower levels, so it could
   potentially be used on many underlying transport protocols, or even
   another remote procedure call implementation.  For ease of
   discussion, the rest of this document will assume NFS is implemented
   on top of Sun RPC, described in  RFC 1057, "RPC: Remote Procedure
   Call Protocol Specification".

1.2.  External Data Representation

   The eXternal Data Representation (XDR) standard provides a common way
   of representing a set of data types over a network.  The NFS Protocol



Sun Microsystems, Inc.                                          [Page 1]

RFC 1094                NFS: Network File System              March 1989


   Specification is written using the RPC data description language.
   For more information, see RFC 1014, "XDR: External Data
   Representation Standard".  Although automated RPC/XDR compilers exist
   to generate server and client "stubs", NFS does not require their
   use.  Any software that provides equivalent functionality can be
   used, and if the encoding is exactly the same it can interoperate
   with other implementations of NFS.

1.3.  Stateless Servers

   The NFS protocol was intended to be as stateless as possible.  That
   is, a server should not need to maintain any protocol state
   information about any of its clients in order to function correctly.
   Stateless servers have a distinct advantage over stateful servers in
   the event of a failure.  With stateless servers, a client need only
   retry a request until the server responds; it does not even need to
   know that the server has crashed, or the network temporarily went
   down.  The client of a stateful server, on the other hand, needs to
   either detect a server failure and rebuild the server's state when it
   comes back up, or cause client operations to fail.

   This may not sound like an important issue, but it affects the
   protocol in some unexpected ways.  We feel that it may be worth a bit
   of extra complexity in the protocol to be able to write very simple
   servers that do not require fancy crash recovery.  Note that even if
   a so-called "reliable" transport protocol such as TCP is used, the
   client must still be able to handle interruptions of service by re-
   opening connections when they time out.  Thus, a stateless protocol
   may actually simplify the  implementation.

   On the other hand, NFS deals with objects such as files and
   directories that inherently have state -- what good would a file be
   if it did not keep its contents intact?  The goal was to not
   introduce any extra state in the protocol itself.  Inherently
   stateful operations such as file or record locking, and remote
   execution,  were implemented as separate services, not described in
   this document.

   The basic way to simplify recovery was to make operations as
   "idempotent" as possible (so that they can potentially be repeated).
   Some operations in this version of the protocol did not attain this
   goal; luckily most of the operations (such as Read and Write) are
   idempotent.  Also, most server failures occur between operations, not
   between the receipt of an operation and the response.  Finally,
   although actual server failures may be rare, in complex networks,
   failures of any network, router, or bridge may be indistinguishable
   from a server failure.




Sun Microsystems, Inc.                                          [Page 2]

RFC 1094                NFS: Network File System              March 1989


2. 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.

2.1.  File System Model

   NFS assumes a file system that is hierarchical, with directories as
   all but the bottom level of files.  Each entry in a directory (file,
   directory, device, etc.) has a string name.  Different operating
   systems may have restrictions on the depth of the tree or the names
   used, as well as using different syntax to represent the "pathname",
   which is the concatenation of all the "components" (directory and
   file names) in the name.  A "file system" is a tree on a single
   server (usually a single disk or physical partition) with a specified
   "root".  Some operating systems provide a "mount" operation to make
   all file systems appear as a single tree, while others maintain a
   "forest" of file systems.  Files are unstructured streams of
   uninterpreted bytes.  Version 3 of NFS uses slightly more general
   file system model.

   NFS looks up one component of a pathname at a time.  It may not be
   obvious why it does not just take the whole pathname, traipse down
   the directories, and return a file handle when it is done.  There are
   several good reasons not to do this.  First, pathnames need
   separators between the directory components, and different operating
   systems use different separators.  We could define a Network Standard
   Pathname Representation, but then every pathname would have to be
   parsed and converted at each end.  Other issues are discussed in
   section 3, NFS Implementation Issues.

   Although files and directories are similar objects in many ways,
   different procedures are used to read directories and files.  This
   provides a network standard format for representing directories.  The
   same argument as above could have been used to justify a procedure
   that returns only one directory entry per call.  The problem is
   efficiency.  Directories can contain many entries, and a remote call
   to return each would be just too slow.

2.2.  Server Procedures

   The protocol definition is given as a set of procedures with
   arguments and results defined using the RPC language (XDR language
   extended with program, version, and procedure declarations).  A brief



Sun Microsystems, Inc.                                          [Page 3]

RFC 1094                NFS: Network File System              March 1989


   description of the function of each procedure should provide enough
   information to allow implementation.  Section 2.3 describes the basic
   data types in more detail.

   All of the procedures in the NFS protocol are assumed to be
   synchronous.  When a procedure returns to the client, the client can
   assume that the operation has completed and any data associated with
   the request is now on stable storage.  For example, a client WRITE
   request may cause the server to update data blocks, filesystem
   information blocks (such as indirect blocks), and file attribute
   information (size and modify times).  When the WRITE returns to the
   client, it can assume that the write is safe, even in case of a
   server crash, and it can discard the data written.  This is a very
   important part of the statelessness of the server.  If the server
   waited to flush data from remote requests, the client would have to
   save those requests so that it could resend them in case of a server
   crash.

           /*
            * Remote file service routines
            */
           program NFS_PROGRAM {
                   version NFS_VERSION {
                           void
                           NFSPROC_NULL(void)              = 0;

                           attrstat
                           NFSPROC_GETATTR(fhandle)        = 1;

                           attrstat
                           NFSPROC_SETATTR(sattrargs)      = 2;

                           void
                           NFSPROC_ROOT(void)              = 3;

                           diropres
                           NFSPROC_LOOKUP(diropargs)       = 4;

                           readlinkres
                           NFSPROC_READLINK(fhandle)       = 5;

                           readres
                           NFSPROC_READ(readargs)          = 6;

                           void
                           NFSPROC_WRITECACHE(void)        = 7;





Sun Microsystems, Inc.                                          [Page 4]

RFC 1094                NFS: Network File System              March 1989


                           attrstat
                           NFSPROC_WRITE(writeargs)        = 8;

                           diropres
                           NFSPROC_CREATE(createargs)      = 9;

                           stat
                           NFSPROC_REMOVE(diropargs)       = 10;

                           stat
                           NFSPROC_RENAME(renameargs)      = 11;

                           stat
                           NFSPROC_LINK(linkargs)          = 12;

                           stat
                           NFSPROC_SYMLINK(symlinkargs)    = 13;

                           diropres
                           NFSPROC_MKDIR(createargs)       = 14;

                           stat
                           NFSPROC_RMDIR(diropargs)        = 15;

                           readdirres
                           NFSPROC_READDIR(readdirargs)    = 16;

                           statfsres
                           NFSPROC_STATFS(fhandle)         = 17;
                   } = 2;
           } = 100003;

2.2.1.  Do Nothing

           void
           NFSPROC_NULL(void) = 0;

   This procedure does no work.  It is made available in all RPC
   services to allow server response testing and timing.

2.2.2.  Get File Attributes

           attrstat
           NFSPROC_GETATTR (fhandle) = 1;

   If the reply status is NFS_OK, then the reply attributes contains the
   attributes for the file given by the input fhandle.




Sun Microsystems, Inc.                                          [Page 5]

RFC 1094                NFS: Network File System              March 1989


2.2.3.  Set File Attributes

           struct sattrargs {
                   fhandle file;
                   sattr attributes;
           };

           attrstat
           NFSPROC_SETATTR (sattrargs) = 2;

   The "attributes" argument contains fields which are either -1 or are
   the new value for the attributes of "file".  If the reply status is
   NFS_OK, then the reply attributes have the attributes of the file
   after the "SETATTR" operation has completed.

   Notes:  The use of -1 to indicate an unused field in "attributes" is
   changed in the next version of the protocol.

2.2.4.  Get Filesystem Root

           void
           NFSPROC_ROOT(void) = 3;

   Obsolete.  This procedure is no longer used because finding the root
   file handle of a filesystem requires moving pathnames between client
   and server.  To do this right, we would have to define a network
   standard representation of pathnames.  Instead, the function of
   looking up the root file handle is done by the MNTPROC_MNT procedure.
   (See Appendix A, "Mount Protocol Definition", for details).

2.2.5.  Look Up File Name

           diropres
           NFSPROC_LOOKUP(diropargs) = 4;

   If the reply "status" is NFS_OK, then the reply "file" and reply
   "attributes" are the file handle and attributes for the file "name"
   in the directory given by "dir" in the argument.

2.2.6.  Read From Symbolic Link

           union readlinkres switch (stat status) {
           case NFS_OK:
               path data;
           default:
               void;
           };




Sun Microsystems, Inc.                                          [Page 6]

RFC 1094                NFS: Network File System              March 1989


           readlinkres
           NFSPROC_READLINK(fhandle) = 5;

   If "status" has the value NFS_OK, then the reply "data" is the data
   in the symbolic link given by the file referred to by the fhandle
   argument.

   Notes:  Since NFS always parses pathnames on the client, the pathname
   in a symbolic link may mean something different (or be meaningless)
   on a different client or on the server if a different pathname syntax
   is used.

2.2.7.  Read From File

           struct readargs {
                   fhandle file;
                   unsigned offset;
                   unsigned count;
                   unsigned totalcount;
           };

           union readres switch (stat status) {
           case NFS_OK:
                   fattr attributes;
                   nfsdata data;
           default:
                   void;
           };

           readres
           NFSPROC_READ(readargs) = 6;

   Returns up to "count" bytes of "data" from the file given by "file",
   starting at "offset" bytes from the beginning of the file.  The first
   byte of the file is at offset zero.  The file attributes after the
   read takes place are returned in "attributes".