You might also mention that none of this description is applicable to NFSv4, which doesn't use any of the protocols controlled by the mountproto option. Tom. At 12:16 PM 9/23/2008, Chuck Lever wrote: >Document the interaction between the mountproto= and the proto= mount >options in a new subsection of nfs(5). > >Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> >--- > > utils/mount/nfs.man | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 81 insertions(+), 0 deletions(-) > >diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man >index b1037a8..48f2153 100644 >--- a/utils/mount/nfs.man >+++ b/utils/mount/nfs.man >@@ -831,6 +831,87 @@ and > .B wsize > can safely be allowed to default to the largest values supported by > both client and server, independent of the network's MTU size. >+.SS "Interaction between the proto and mountproto options" >+The Linux NFS client can use a different transport protocol for >+contacting an NFS server's rpcbind service, its mountd service, >+its NLM service, and its NFS service. >+The exact transport protocols employed by the Linux NFS client for >+each mount point depends on the settings of the transport protocol >+mount options, which include >+.BR proto , >+.BR mountproto , >+.BR udp ", and " tcp . >+.P >+The NSM protocol uses the UDP transport >+no matter what transport specific options are specified. >+The NFSACL protocol shares the same RPC transport as the main NFS >+service. >+.P >+If no transport protocol options are specified, the Linux NFS client >+uses UDP to contact the server's mountd service, and TCP to >+contact its NLM and NFS services by default. >+.P >+UDP is a good choice for contacting the mountd server since most >+common NFS servers support UDP for mountd, UDP generates less network >+traffic, and UDP does not leave extra ports in TIME_WAIT after the >+mountd request is complete. >+However, a reliable stream transport such as TCP is a good choice for >+NFS and NLM because these must handle large requests and must be >+immune to network problems that might cause RPC requests to be lost. >+.P >+If the server does not support these transports for these services, the >+.BR mount (8) >+command attempts to discover what the server supports, and then retries >+the mount request once using the discovered transport protocols. >+If the server does not advertise any transport supported by the client >+or is misconfigured, the mount request fails. >+If the >+.B bg >+option is in effect, the mount command backgrounds itself and continues >+to attempt the specified mount request. >+.P >+When the >+.B proto >+option, the >+.B udp >+option, or the >+.B tcp >+option is specified but the >+.B mountproto >+option is not, the specified transport is used to contact >+both the server's mountd service and for the NLM and NFS services. >+.P >+If the >+.B mountproto >+option is specified but none of the >+.BR proto ", " udp " or " tcp >+options are specified, then the specified transport is used for the >+initial mountd request, but the mount command attempts to discover >+what the server supports for the NFS protocol, preferring TCP if >+both transports are supported. >+.P >+If both the >+.BR mountproto " and " proto >+(or >+.BR udp " or " tcp ) >+options are specified, then the transport specified by the >+.B mountproto >+option is used for the initial mountd request, and the transport >+specified by the >+.B proto >+option (or the >+.BR udp " or " tcp " options)" >+is used for NFS, no matter what order these options appear. >+No automatic service discovery is performed if these options are >+specified. >+.P >+If any of the >+.BR proto ", " udp ", " tcp ", " >+or >+.B mountproto >+options are specified more than once on the same mount command line, >+then the value of the rightmost instance of each of these options >+takes effect. > .SH "DATA AND METADATA COHERENCE" > Some modern cluster file systems provide > perfect cache coherence among their clients. > >-- >To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
