rfc1813.txt

RFC 的详细文档！

      struct wcc_data {
         pre_op_attr    before;
         post_op_attr   after;
      };

   When a client performs an operation that modifies the state of a
   file or directory on the server, it cannot immediately determine
   from the post-operation attributes whether the operation just
   performed was the only operation on the object since the last
   time the client received the attributes for the object. This is
   important, since if an intervening operation has changed the
   object, the client will need to invalidate any cached data for
   the object (except for the data that it just wrote).

   To deal with this, the notion of weak cache consistency data or
   wcc_data is introduced. A wcc_data structure consists of certain
   key fields from the object attributes before the operation,
   together with the object attributes after the operation. This



Callaghan, el al             Informational                     [Page 24]

RFC 1813                 NFS Version 3 Protocol                June 1995


   information allows the client to manage its cache more
   accurately than in NFS version 2 protocol implementations. The
   term, weak cache consistency, emphasizes the fact that this
   mechanism does not provide the strict server-client consistency
   that a cache consistency protocol would provide.

   In order to support the weak cache consistency model, the server
   will need to be able to get the pre-operation attributes of the
   object, perform the intended modify operation, and then get the
   post-operation attributes atomically. If there is a window for
   the object to get modified between the operation and either of
   the get attributes operations, then the client will not be able
   to determine whether it was the only entity to modify the
   object. Some information will have been lost, thus weakening the
   weak cache consistency guarantees.

   post_op_fh3

      union post_op_fh3 switch (bool handle_follows) {
      case TRUE:
           nfs_fh3  handle;
      case FALSE:
           void;
      };

   One of the principles of this revision of the NFS protocol is to
   return the real value from the indicated operation and not an
   error from an incidental operation. The post_op_fh3 structure
   was designed to allow the server to recover from errors
   encountered while constructing a file handle.

   This is the structure used to return a file handle from the
   CREATE, MKDIR, SYMLINK, MKNOD, and READDIRPLUS requests. In each
   case, the client can get the file handle by issuing a LOOKUP
   request after a successful return from one of the listed
   operations. Returning the file handle is an optimization so that
   the client is not forced to immediately issue a LOOKUP request
   to get the file handle.

   sattr3

      enum time_how {
         DONT_CHANGE        = 0,
         SET_TO_SERVER_TIME = 1,
         SET_TO_CLIENT_TIME = 2
      };

      union set_mode3 switch (bool set_it) {



Callaghan, el al             Informational                     [Page 25]

RFC 1813                 NFS Version 3 Protocol                June 1995


      case TRUE:
         mode3    mode;
      default:
         void;
      };

      union set_uid3 switch (bool set_it) {
      case TRUE:
         uid3     uid;
      default:
         void;
      };

      union set_gid3 switch (bool set_it) {
      case TRUE:
         gid3     gid;
      default:
         void;
      };

      union set_size3 switch (bool set_it) {
      case TRUE:
         size3    size;
      default:
         void;
      };

      union set_atime switch (time_how set_it) {
      case SET_TO_CLIENT_TIME:
         nfstime3  atime;
      default:
         void;
      };

      union set_mtime switch (time_how set_it) {
      case SET_TO_CLIENT_TIME:
         nfstime3  mtime;
      default:
         void;
      };

      struct sattr3 {
         set_mode3   mode;
         set_uid3    uid;
         set_gid3    gid;
         set_size3   size;
         set_atime   atime;
         set_mtime   mtime;



Callaghan, el al             Informational                     [Page 26]

RFC 1813                 NFS Version 3 Protocol                June 1995


      };

   The sattr3 structure contains the file attributes that can be
   set from the client. The fields are the same as the similarly
   named fields in the fattr3 structure. In the NFS version 3
   protocol, the settable attributes are described by a structure
   containing a set of discriminated unions. Each union indicates
   whether the corresponding attribute is to be updated, and if so,
   how.

   There are two forms of discriminated unions used. In setting the
   mode, uid, gid, or size, the discriminated union is switched on
   a boolean, set_it; if it is TRUE, a value of the appropriate
   type is then encoded.

   In setting the atime or mtime, the union is switched on an
   enumeration type, set_it. If set_it has the value DONT_CHANGE,
   the corresponding attribute is unchanged. If it has the value,
   SET_TO_SERVER_TIME, the corresponding attribute is set by the
   server to its local time; no data is provided by the client.
   Finally, if set_it has the value, SET_TO_CLIENT_TIME, the
   attribute is set to the time passed by the client in an nfstime3
   structure. (See FSINFO on page 86, which addresses the issue of
   time granularity).

   diropargs3

      struct diropargs3 {
         nfs_fh3     dir;
         filename3   name;
      };

   The diropargs3 structure is used in directory operations. The
   file handle, dir, identifies the directory in which to
   manipulate or access the file, name. See additional comments in
   File name component handling on page 101.

3. Server Procedures

   The following sections define the RPC procedures that are
   supplied by an NFS version 3 protocol server. The RPC
   procedure number is given at the top of the page with the
   name. The SYNOPSIS provides the name of the procedure, the
   list of the names of the arguments, the list of the names of
   the results, followed by the XDR argument declarations and
   results declarations. The information in the SYNOPSIS is
   specified in RPC Data Description Language as defined in
   [RFC1014]. The DESCRIPTION section tells what the procedure



Callaghan, el al             Informational                     [Page 27]

RFC 1813                 NFS Version 3 Protocol                June 1995


   is expected to do and how its arguments and results are used.
   The ERRORS section lists the errors returned for specific
   types of failures. These lists are not intended to be the
   definitive statement of all of the errors which can be
   returned by any specific procedure, but as a guide for the
   more common errors which may be returned.  Client
   implementations should be prepared to deal with unexpected
   errors coming from a server. The IMPLEMENTATION field gives
   information about how the procedure is expected to work and
   how it should be used by clients.

      program NFS_PROGRAM {
         version NFS_V3 {

            void
             NFSPROC3_NULL(void)                    = 0;

            GETATTR3res
             NFSPROC3_GETATTR(GETATTR3args)         = 1;

            SETATTR3res
             NFSPROC3_SETATTR(SETATTR3args)         = 2;

            LOOKUP3res
             NFSPROC3_LOOKUP(LOOKUP3args)           = 3;

            ACCESS3res
             NFSPROC3_ACCESS(ACCESS3args)           = 4;

            READLINK3res
             NFSPROC3_READLINK(READLINK3args)       = 5;

            READ3res
             NFSPROC3_READ(READ3args)               = 6;

            WRITE3res
             NFSPROC3_WRITE(WRITE3args)             = 7;

            CREATE3res
             NFSPROC3_CREATE(CREATE3args)           = 8;

            MKDIR3res
             NFSPROC3_MKDIR(MKDIR3args)             = 9;

            SYMLINK3res
             NFSPROC3_SYMLINK(SYMLINK3args)         = 10;





Callaghan, el al             Informational                     [Page 28]

RFC 1813                 NFS Version 3 Protocol                June 1995


            MKNOD3res
             NFSPROC3_MKNOD(MKNOD3args)             = 11;

            REMOVE3res
             NFSPROC3_REMOVE(REMOVE3args)           = 12;

            RMDIR3res
             NFSPROC3_RMDIR(RMDIR3args)             = 13;

            RENAME3res
             NFSPROC3_RENAME(RENAME3args)           = 14;

            LINK3res
             NFSPROC3_LINK(LINK3args)               = 15;

            READDIR3res
             NFSPROC3_READDIR(READDIR3args)         = 16;

            READDIRPLUS3res
             NFSPROC3_READDIRPLUS(READDIRPLUS3args) = 17;

            FSSTAT3res
             NFSPROC3_FSSTAT(FSSTAT3args)           = 18;

            FSINFO3res
             NFSPROC3_FSINFO(FSINFO3args)           = 19;

            PATHCONF3res
             NFSPROC3_PATHCONF(PATHCONF3args)       = 20;

            COMMIT3res
             NFSPROC3_COMMIT(COMMIT3args)           = 21;

         } = 3;
      } = 100003;

   Out of range (undefined) procedure numbers result in RPC
   errors.  Refer to [RFC1057] for more detail.

3.1 General comments on attributes and consistency data on failure

   For those procedures that return either post_op_attr or wcc_data
   structures on failure, the discriminated union may contain the
   pre-operation attributes of the object or object parent
   directory.  This depends on the error encountered and may also
   depend on the particular server implementation. Implementors are
   strongly encouraged to return as much attribute data as possible
   upon failure, but client implementors need to be aware that



Callaghan, el al             Informational                     [Page 29]

RFC 1813                 NFS Version 3 Protocol                June 1995


   their implementation must correctly handle the variant return
   instance where no attributes or consistency data is returned.

3.2 General comments on filenames

   The following comments apply to all NFS version 3 protocol
   procedures in which the client provides one or more filenames in
   the arguments: LOOKUP, CREATE, MKDIR, SYMLINK, MKNOD, REMOVE,
   RMDIR, RENAME, and LINK.

   1. The filename must not be null nor may it be the null
      string.  The server should return the error, NFS3ERR_ACCES, if
      it receives such a filename. On some clients, the filename, ``''
      or a null string, is assumed to be an alias for the current
      directory. Clients which require this functionality should
      implement it for themselves and not depend upon the server to
      support such semantics.

   2. A filename having the value of "." is assumed to be an
      alias for the current directory. Clients which require this
      functionality