rfc1094.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,515 行 · 第 1/4 页

   These are the sizes, given in decimal bytes, of various XDR
   structures used in the protocol:

   /*
    * The maximum number of bytes of data in a READ or WRITE
    * request.
    */
   const MAXDATA = 8192;

   /* The maximum number of bytes in a pathname argument. */
   const MAXPATHLEN = 1024;

   /* The maximum number of bytes in a file name argument. */
   const MAXNAMLEN = 255;

   /* The size in bytes of the opaque "cookie" passed by READDIR. */
   const COOKIESIZE  = 4;

   /* The size in bytes of the opaque file handle. */
   const FHSIZE = 32;

3.6. Setting RPC Parameters

   Various file system parameters and options should be set at mount
   time.  The mount protocol is described in the appendix below.  For
   example, "Soft" mounts as well as "Hard" mounts are usually both
   provided.  Soft mounted file systems return errors when RPC
   operations fail (after a given number of optional retransmissions),
   while hard mounted file systems continue to retransmit forever.  The
   maximum transfer sizes are implementation dependent.  For efficient
   operation over a local network, 8192 bytes of data are normally used.
   This may result in lower-level fragmentation (such as at the IP
   level).  Since some network interfaces may not allow such packets,
   for operation over slower-speed networks or hosts, or through
   gateways, transfer sizes of 512 or 1024 bytes often provide better
   results.



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


   Clients and servers may need to keep caches of recent operations to
   help avoid problems with non-idempotent operations.  For example, if
   the transport protocol drops the response for a Remove File
   operation, upon retransmission the server may return an error code of
   NFSERR_NOENT instead of NFS_OK.  But if the server keeps around the
   last operation requested and its result, it could return the proper
   success code.  Of course, the server could be crashed and rebooted
   between retransmissions, but a small cache (even a single entry)
   would solve most problems.










































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


                   Appendix A. MOUNT PROTOCOL DEFINITION

A.1.  Introduction

   The mount protocol is separate from, but related to, the NFS
   protocol.  It provides operating system specific services to get the
   NFS off the ground -- looking up server path names, validating user
   identity, and checking access permissions.  Clients use the mount
   protocol to get the first file handle, which allows them entry into a
   remote filesystem.

   The mount protocol is kept separate from the NFS protocol to make it
   easy to plug in new access checking and validation methods without
   changing the NFS server protocol.

   Notice that the protocol definition implies stateful servers because
   the server maintains a list of client's mount requests.  The mount
   list information is not critical for the correct functioning of
   either the client or the server.  It is intended for advisory use
   only, for example, to warn possible clients when a server is going
   down.

   Version one of the mount protocol is used with version two of the NFS
   protocol.  The only information communicated between these two
   protocols is the "fhandle" structure.

A.2.  RPC Information

   Authentication
      The mount service uses AUTH_UNIX and AUTH_NONE style
      authentication only.

   Transport Protocols
      The mount service is supported on both UDP and TCP.

   Port Number
      Consult the server's portmapper, described in RFC 1057, "RPC:
      Remote Procedure Call Protocol Specification", to find the port
      number on which the mount service is registered.

A.3.  Sizes of XDR Structures

   These are the sizes, given in decimal bytes, of various XDR
   structures used in the protocol:

           /* The maximum number of bytes in a pathname argument. */
           const MNTPATHLEN = 1024;




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


           /* The maximum number of bytes in a name argument. */
           const MNTNAMLEN = 255;

           /* The size in bytes of the opaque file handle. */
           const FHSIZE = 32;

A.4.  Basic Data Types

   This section presents the data types used by the mount protocol.  In
   many cases they are similar to the types used in NFS.

A.4.1.  fhandle

       typedef opaque fhandle[FHSIZE];

   The type "fhandle" is the file handle that the server passes to the
   client.  All file operations are done using file handles to refer to
   a file or directory.  The file handle can contain whatever
   information the server needs to distinguish an individual file.

   This is the same as the "fhandle" XDR definition in version 2 of the
   NFS protocol; see section "2.3.3. fhandle" under "Basic Data Types".

A.4.2.  fhstatus

       union fhstatus switch (unsigned status) {
       case 0:
           fhandle directory;
       default:
           void;
       }

   The type "fhstatus" is a union.  If a "status" of zero is returned,
   the call completed successfully, and a file handle for the
   "directory" follows.  A non-zero status indicates some sort of error.
   In this case, the status is a UNIX error number.

A.4.3.  dirpath

       typedef string dirpath<MNTPATHLEN>;

   The type "dirpath" is a server pathname of a directory.

A.4.4.  name

       typedef string name<MNTNAMLEN>;

   The type "name" is an arbitrary string used for various names.



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


A.5.  Server Procedures

   The following sections define the RPC procedures supplied by a mount
   server.

           /*
            * Protocol description for the mount program
            */
           program MOUNTPROG {
                   /*
                    * Version 1 of the mount protocol used with
                    * version 2 of the NFS protocol.
                    */
                   version MOUNTVERS {

                           void
                           MOUNTPROC_NULL(void) = 0;

                           fhstatus
                           MOUNTPROC_MNT(dirpath) = 1;

                           mountlist
                           MOUNTPROC_DUMP(void) = 2;

                           void
                           MOUNTPROC_UMNT(dirpath) = 3;

                           void
                           MOUNTPROC_UMNTALL(void) = 4;

                           exportlist
                           MOUNTPROC_EXPORT(void)  = 5;
                   } = 1;
           } = 100005;

A.5.1.  Do Nothing

           void
           MNTPROC_NULL(void) = 0;

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

A.5.2.  Add Mount Entry

           fhstatus
           MNTPROC_MNT(dirpath) = 1;




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


   If the reply "status" is 0, then the reply "directory" contains the
   file handle for the directory "dirname".  This file handle may be
   used in the NFS protocol.  This procedure also adds a new entry to
   the mount list for this client mounting "dirname".

A.5.3.  Return Mount Entries

           struct *mountlist {
                   name      hostname;
                   dirpath   directory;
                   mountlist nextentry;
           };

           mountlist
           MNTPROC_DUMP(void) = 2;

   Returns the list of remote mounted filesystems.  The "mountlist"
   contains one entry for each "hostname" and "directory" pair.

A.5.4.  Remove Mount Entry

           void
           MNTPROC_UMNT(dirpath) = 3;

   Removes the mount list entry for the input "dirpath".

A.5.5.  Remove All Mount Entries

           void
           MNTPROC_UMNTALL(void) = 4;

   Removes all of the mount list entries for this client.

A.5.6.  Return Export List

           struct *groups {
                   name grname;
                   groups grnext;
           };

           struct *exportlist {
                   dirpath filesys;
                   groups groups;
                   exportlist next;
           };

           exportlist
           MNTPROC_EXPORT(void) = 5;



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


   Returns a variable number of export list entries.  Each entry
   contains a filesystem name and a list of groups that are allowed to
   import it.  The filesystem name is in "filesys", and the group name
   is in the list "groups".

   Notes:  The exportlist should contain more information about the
   status of the filesystem, such as a read-only flag.

Author's Address:

   Bill Nowicki
   Sun Microsystems, Inc.
   Mail Stop 1-40
   2550 Garcia Avenue
   Mountain View, CA 94043

   Phone: [phone]

   Email: [e-mail]
































Sun Microsystems, Inc.                                         [Page 27]