From: "Chuck Lever" Subject: Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options Date: Tue, 23 Sep 2008 12:47:32 -0400 Message-ID: <76bd70e30809230947v7c0a162x4ef73ddcbe258c08@mail.gmail.com> References: <20080923161322.5119.20872.stgit@manray.1015granger.net> <20080923161641.5119.37034.stgit@manray.1015granger.net> Reply-To: chucklever@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: steved@redhat.com, linux-nfs@vger.kernel.org To: "Talpey, Thomas" Return-path: Received: from ug-out-1314.google.com ([66.249.92.170]:42475 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755268AbYIWQre (ORCPT ); Tue, 23 Sep 2008 12:47:34 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1661686ugf.37 for ; Tue, 23 Sep 2008 09:47:32 -0700 (PDT) In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, Sep 23, 2008 at 12:32 PM, Talpey, Thomas wrote: > 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. Good point, that should be made more clear. > 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 >>--- >> >> 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@vger.kernel.org >>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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- "If you simplify your English, you are freed from the worst follies of orthodoxy." -- George Orwell