Document the interaction between the mountproto= and the proto= mount
options in a new subsection of nfs(5).
Signed-off-by: Chuck Lever <[email protected]>
---
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.
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 <[email protected]>
>---
>
> 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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
One other comment...
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 <[email protected]>
>---
>
> 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.
This actually isn't true - in fact the client NSM by default listens on
both UDP and TCP, as can be seen with rpcinfo -p.
What is true is that the vast majority of NFS servers call back on UDP,
and if this fails, there is no indication at the client whatsoever.
So the text should perhaps say "NFS servers typically choose UDP for the
NSM protocol; the client in any case accepts both UDP and TCP."
Tom.
>+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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 23, 2008 at 12:32 PM, Talpey, Thomas
<[email protected]> 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 <[email protected]>
>>---
>>
>> 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 [email protected]
>>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 [email protected]
> 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
On Tue, Sep 23, 2008 at 12:41 PM, Talpey, Thomas
<[email protected]> wrote:
> One other comment...
>
> 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 <[email protected]>
>>---
>>
>> 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.
>
> This actually isn't true - in fact the client NSM by default listens on
> both UDP and TCP, as can be seen with rpcinfo -p.
>
> What is true is that the vast majority of NFS servers call back on UDP,
> and if this fails, there is no indication at the client whatsoever.
>
> So the text should perhaps say "NFS servers typically choose UDP for the
> NSM protocol; the client in any case accepts both UDP and TCP."
Granted that this text should be tuned a bit, but...
Even though rpc.statd listens on TCP as well, Linux sm-notify requests
go out only on UDP; and there is no mount option to change any of this
behavior.
NSM is a bit of a challenge to describe because both ends act as a
client and a server.
--
Chuck Lever