rfc1813.txt

RFC 的详细文档！

   foo is an 8 byte signed value, while bar is an 8 byte unsigned
   value.



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


   Although RPC/XDR compilers exist to generate client and server
   stubs from RPC Data Description Language input, NFS
   implementations do not require their use. Any software that
   provides equivalent encoding and decoding to the canonical
   network order of data defined by XDR can be used to interoperate
   with other NFS implementations.

   XDR is described in [RFC1014].

1.5 Authentication and Permission Checking

   The RPC protocol includes a slot for authentication parameters
   on every call. The contents of the authentication parameters are
   determined by the type of authentication used by the server and
   client. A server may support several different flavors of
   authentication at once. The AUTH_NONE flavor provides null
   authentication, that is, no authentication information is
   passed. The AUTH_UNIX flavor provides UNIX-style user ID, group
   ID, and groups with each call. The AUTH_DES flavor provides
   DES-encrypted authentication parameters based on a network-wide
   name, with session keys exchanged via a public key scheme. The
   AUTH_KERB flavor provides DES encrypted authentication
   parameters based on a network-wide name with session keys
   exchanged via Kerberos secret keys.

   The NFS server checks permissions by taking the credentials from
   the RPC authentication information in each remote request. For
   example, using the AUTH_UNIX flavor of authentication, the
   server gets the user's effective user ID, effective group ID and
   groups on each call, and uses them to check access. Using user
   ids and group ids implies that the client and server either
   share the same ID list or do local user and group ID mapping.
   Servers and clients must agree on the mapping from user to uid
   and from group to gid, for those sites that do not implement a
   consistent user ID and group ID space. In practice, such mapping
   is typically performed on the server, following a static mapping
   scheme or a mapping established by the user from a client at
   mount time.

   The AUTH_DES and AUTH_KERB style of authentication is based on a
   network-wide name. It provides greater security through the use
   of DES encryption and public keys in the case of AUTH_DES, and
   DES encryption and Kerberos secret keys (and tickets) in the
   AUTH_KERB case. Again, the server and client must agree on the
   identity of a particular name on the network, but the name to
   identity mapping is more operating system independent than the
   uid and gid mapping in AUTH_UNIX. Also, because the
   authentication parameters are encrypted, a malicious user must



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


   know another users network password or private key to masquerade
   as that user. Similarly, the server returns a verifier that is
   also encrypted so that masquerading as a server requires knowing
   a network password.

   The NULL procedure typically requires no authentication.

1.6 Philosophy

   This specification defines the NFS version 3 protocol, that is
   the over-the-wire protocol by which a client accesses a server.
   The protocol provides a well-defined interface to a server's
   file resources. A client or server implements the protocol and
   provides a mapping of the local file system semantics and
   actions into those defined in the NFS version 3 protocol.
   Implementations may differ to varying degrees, depending on the
   extent to which a given environment can support all the
   operations and semantics defined in the NFS version 3 protocol.
   Although implementations exist and are used to illustrate
   various aspects of the NFS version 3 protocol, the protocol
   specification itself is the final description of how clients
   access server resources.

   Because the NFS version 3 protocol is designed to be
   operating-system independent, it does not necessarily match the
   semantics of any existing system. Server implementations are
   expected to make a best effort at supporting the protocol.  If a
   server cannot support a particular protocol procedure, it may
   return the error, NFS3ERR_NOTSUP, that indicates that the
   operation is not supported.  For example, many operating systems
   do not support the notion of a hard link. A server that cannot
   support hard links should return NFS3ERR_NOTSUP in response to a
   LINK request. FSINFO describes the most commonly unsupported
   procedures in the properties bit map.  Alternatively, a server
   may not natively support a given operation, but can emulate it
   in the NFS version 3 protocol implementation to provide greater
   functionality.

   In some cases, a server can support most of the semantics
   described by the protocol but not all. For example, the ctime
   field in the fattr structure gives the time that a file's
   attributes were last modified. Many systems do not keep this
   information. In this case, rather than not support the GETATTR
   operation, a server could simulate it by returning the last
   modified time in place of ctime.  Servers must be careful when
   simulating attribute information because of possible side
   effects on clients. For example, many clients use file
   modification times as a basis for their cache consistency



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


   scheme.

   NFS servers are dumb and NFS clients are smart. It is the
   clients that do the work required to convert the generalized
   file access that servers provide into a file access method that
   is useful to applications and users. In the LINK example given
   above, a UNIX client that received an NFS3ERR_NOTSUP error from
   a server would do the recovery necessary to either make it look
   to the application like the link request had succeeded or return
   a reasonable error. In general, it is the burden of the client
   to recover.

   The NFS version 3 protocol assumes a stateless server
   implementation.  Statelessness means that the server does not
   need to maintain state about any of its clients in order to
   function correctly. Stateless servers have a distinct advantage
   over stateful servers in the event of a crash. With stateless
   servers, a client need only retry a request until the server
   responds; the client does not even need to know that the server
   has crashed. See additional comments in Duplicate request cache
   on page 99.

   For a server to be useful, it holds nonvolatile state: data
   stored in the file system. Design assumptions in the NFS version
   3 protocol regarding flushing of modified data to stable storage
   reduce the number of failure modes in which data loss can occur.
   In this way, NFS version 3 protocol implementations can tolerate
   transient failures, including transient failures of the network.
   In general, server implementations of the NFS version 3 protocol
   cannot tolerate a non-transient failure of the stable storage
   itself. However, there exist fault tolerant implementations
   which attempt to address such problems.

   That is not to say that an NFS version 3 protocol server can't
   maintain noncritical state. In many cases, servers will maintain
   state (cache) about previous operations to increase performance.
   For example, a client READ request might trigger a read-ahead of
   the next block of the file into the server's data cache in the
   anticipation that the client is doing a sequential read and the
   next client READ request will be satisfied from the server's
   data cache instead of from the disk. Read-ahead on the server
   increases performance by overlapping server disk I/O with client
   requests. The important point here is that the read-ahead block
   is not necessary for correct server behavior. If the server
   crashes and loses its memory cache of read buffers, recovery is
   simple on reboot - clients will continue read operations
   retrieving data from the server disk.




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


   Most data-modifying operations in the NFS protocol are
   synchronous.  That is, when a data modifying procedure returns
   to the client, the client can assume that the operation has
   completed and any modified data associated with the request is
   now on stable storage. For example, a synchronous client WRITE
   request may cause the server to update data blocks, file system
   information blocks, and file attribute information - the latter
   information is usually referred to as metadata. When the WRITE
   operation completes, the client can assume that the write data
   is safe and discard it.  This is a very important part of the
   stateless nature of the server. If the server did not flush
   dirty data to stable storage before returning to the client, the
   client would have no way of knowing when it was safe to discard
   modified data. The following data modifying procedures are
   synchronous: WRITE (with stable flag set to FILE_SYNC), CREATE,
   MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK, and COMMIT.

   The NFS version 3 protocol introduces safe asynchronous writes
   on the server, when the WRITE procedure is used in conjunction
   with the COMMIT procedure. The COMMIT procedure provides a way
   for the client to flush data from previous asynchronous WRITE
   requests on the server to stable storage and to detect whether
   it is necessary to retransmit the data. See the procedure
   descriptions of WRITE on page 49 and COMMIT on page 92.

   The LOOKUP procedure is used by the client to traverse
   multicomponent file names (pathnames). Each call to LOOKUP is
   used to resolve one segment of a pathname. There are two reasons
   for restricting LOOKUP to a single segment: it is hard to
   standardize a common format for hierarchical file names and the
   client and server may have different mappings of pathnames to
   file systems. This would imply that either the client must break
   the path name at file system attachment points, or the server
   must know about the client's file system attachment points. In
   NFS version 3 protocol implementations, it is the client that
   constructs the hierarchical file name space using mounts to
   build a hierarchy. Support utilities, such as the Automounter,
   provide a way to manage a shared, consistent image of the file
   name space while still being driven by the client mount
   process.

   Clients can perform caching in varied manner. The general
   practice with the NFS version 2 protocol was to implement a
   time-based client-server cache consistency mechanism. It is
   expected NFS version 3 protocol implementations will use a
   similar mechanism. The NFS version 3 protocol has some explicit
   support, in the form of additional attribute information to
   eliminate explicit attribute checks. However, caching is not



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


   required, nor is any caching policy defined by the protocol.
   Neither the NFS version 2 protocol nor the NFS version 3
   protocol provide a means of maintaining strict client-server
   consistency (and, by implication, consistency across client
   caches).

1.7 Changes from the NFS Version 2 Protocol

   The ROOT and WRITECACHE procedures have been removed. A MKNOD
   procedure has been defined to allow the creation of special
   files, eliminating the overloading of CREATE. Caching on the
   client is not defined nor dictated by the NFS version 3
   protocol, but additional information and hints have been added
   to the protocol to allow clients that implement caching to
   manage their caches more effectively. Procedures that affect the
   attributes of a file or directory may now return the new
   attributes after the operation has completed to optimize out a
   subsequent GETATTR used in validating attribute caches. In
   addition, operations that modify the directory in which the
   target object resides return the old and new attributes of the
   directory to allow clients to implement more intelligent cache
   invalidation procedures.  The ACCESS procedure provides access
   permission checking on the server, the FSSTAT procedure returns
   dynamic information about a file system, the FSINFO procedure
   returns static information about a file system and server, the
   READDIRPLUS procedure returns file handles and attributes in
   addition to directory entries, and the PATHCONF procedure
   returns POSIX pathconf information about a file.

   Below is a list of the important changes between the NFS version
   2 protocol and the NFS version 3 protocol.

   File handle size
         The file handle has been increased to a variable-length
         array of 64 bytes maximum from a fixed array of 32
         bytes. This addresses some known requirements for a
         slightly larger file handle size. The file handle was
         converted from fixed length to variable length to
         reduce local storage and network bandwidth requirements
         for systems which do not utilize the full 64 bytes of
         length.

   Maximum data sizes
         The maximum size of a data transfer used in the READ
         and WRITE procedures is now set by values in the FSINFO
         return structure. In addition, preferred transfer sizes
         are returned by FSINFO. The protocol does not place any
         artificial limits on the maximum transfer sizes.



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


         Filenames and pathnames are now specified as strings of
         variable length. The actual length restrictions are
         determined by the client and server implementations as
         appropriate.  The protocol does not place any
         artificial limits on the length. The error,
         NFS3ERR_NAMETOOLONG, is provided to allow the server to
         return an indication to the client that it received a
         pathname that was too long for it to handle.

   Error return
         Error returns in some instances now return data (for
         example, attributes). nfsstat3 now defines the full set
         of errors that can be returned by a server. No other
         values are allowed.

   File type
         The file type now includes NF3CHR and NF3BLK for
         special files. Attributes for these types include
         subfields for UNIX major and minor devices numbers.
         NF3SOCK and NF3FIFO are now defined for sockets and
         fifos in the file system.

   File attributes
         The blocksize (the size in bytes of a block in the
         file) field has been removed. The mode field no longer
         contains file type information. The size and fileid
         fields have been widened to eight-byte unsigned
         integers from four-byte integers. Major and minor
         device information is now presented in a distinct
         structure.  The blocks field name has been changed to
         used and now contains the total number of bytes used by
         the file. It is also an eight-byte unsigned integer.

   Set file attributes
         In the NFS version 2 protocol, the settable attributes
         were represented by a subset of the file attributes
         structure; the client indicated those attributes which
         were not to be modified by setting the corresponding
         field to -1, overloading some unsigned fields. The set
         file attributes structure now uses a discriminated