[PATCH 0/2] nfs(5) updates

[PATCH 0/2] nfs(5) updates

[Chuck Lever]

Hi Steve-

Here are a couple of updates to nfs(5) that relate to the use of the
NFS client's transport protocol mount options.  They attempt to
address recent concerns about how these options are documented.

Please consider these for the next release of nfs-utils.

---

Chuck Lever (2):
      nfs(5): Clarify behavior of the mountproto= and proto= options
      nfs(5): Replace the term "netid" in mount option descriptions


 utils/mount/nfs.man |   93 ++++++++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 87 insertions(+), 6 deletions(-)

-- 
Chuck Lever

[PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Chuck Lever]

Mike Eisler noted that the use of the term "netid" in the descriptions
of the "proto=" option is not appropriate, since Linux does not allow
"udp6" or "tcp6".

Remove the term "netid" from nfs(5).

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---

 utils/mount/nfs.man |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index 0fc5079..b1037a8 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -411,10 +411,10 @@ for mounting the
 .B nfs
 file system type.
 .TP 1.5i
-.BI proto= netid
+.BI proto= prot
 The transport protocol used by the NFS client
 to transmit requests to the NFS server for this mount point.
-.I netid
+.I prot
 can be either
 .B udp
 or
@@ -489,11 +489,11 @@ or the server's mountd service is not available on the advertised port.
 This option can be used when mounting an NFS server
 through a firewall that blocks the rpcbind protocol.
 .TP 1.5i
-.BI mountproto= netid
+.BI mountproto= prot
 The transport protocol used by the NFS client
 to transmit requests to the NFS server's mountd service when performing
 this mount request, and when later unmounting this mount point.
-.I netid
+.I prot
 can be either
 .B udp
 or
@@ -638,10 +638,10 @@ for mounting the
 .B nfs4
 file system type.
 .TP 1.5i
-.BI proto= netid
+.BI proto= prot
 The transport protocol used by the NFS client
 to transmit requests to the NFS server for this mount point.
-.I netid
+.I prot
 can be either
 .B udp
 or

[PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Chuck Lever]

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@oracle.com>
---

 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.

Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Talpey, Thomas]

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@oracle.com>
>---
>
> 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

Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Chuck Lever]

On Tue, Sep 23, 2008 at 12:32 PM, Talpey, Thomas
<Thomas.Talpey@netapp.com> 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 <chuck.lever@oracle.com>
>>---
>>
>> 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

Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Talpey, Thomas]

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 <chuck.lever@oracle.com>
>---
>
> 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Chuck Lever]

On Tue, Sep 23, 2008 at 12:41 PM, Talpey, Thomas
<Thomas.Talpey@netapp.com> 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 <chuck.lever@oracle.com>
>>---
>>
>> 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

Re: [PATCH 2/2] nfs(5): Clarify behavior of the mountproto= and proto= options

[Steve Dickson]

Is this ready to go??

steved.

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@oracle.com>
> ---
> 
>  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.
> 

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Talpey, Thomas]

To be pedantic, identifiying this field as a "prot" may be just as
misleading. For example "rdma" (which isn't mentioned btw ;-) )
can employ tcp - iWARP adapters do this.

I think instead that the proto= field simply names the "transport"
rather than "netid" or "prot". Also, I think "prot" is much too easily
mistaken for "port".

So I suggest changing the example to "proto=transport", and deleting
the word "protocol" in the text, simply leaving "the transport used by
NFS to transmit..."

Tom.

At 12:16 PM 9/23/2008, Chuck Lever wrote:
>Mike Eisler noted that the use of the term "netid" in the descriptions
>of the "proto=" option is not appropriate, since Linux does not allow
>"udp6" or "tcp6".
>
>Remove the term "netid" from nfs(5).
>
>Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>---
>
> utils/mount/nfs.man |   12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
>index 0fc5079..b1037a8 100644
>--- a/utils/mount/nfs.man
>+++ b/utils/mount/nfs.man
>@@ -411,10 +411,10 @@ for mounting the
> .B nfs
> file system type.
> .TP 1.5i
>-.BI proto= netid
>+.BI proto= prot
> The transport protocol used by the NFS client
> to transmit requests to the NFS server for this mount point.
>-.I netid
>+.I prot
> can be either
> .B udp
> or
>@@ -489,11 +489,11 @@ or the server's mountd service is not available 
>on the advertised port.
> This option can be used when mounting an NFS server
> through a firewall that blocks the rpcbind protocol.
> .TP 1.5i
>-.BI mountproto= netid
>+.BI mountproto= prot
> The transport protocol used by the NFS client
> to transmit requests to the NFS server's mountd service when performing
> this mount request, and when later unmounting this mount point.
>-.I netid
>+.I prot
> can be either
> .B udp
> or
>@@ -638,10 +638,10 @@ for mounting the
> .B nfs4
> file system type.
> .TP 1.5i
>-.BI proto= netid
>+.BI proto= prot
> The transport protocol used by the NFS client
> to transmit requests to the NFS server for this mount point.
>-.I netid
>+.I prot
> can be either
> .B udp
> or
>
>--
>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

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Chuck Lever]

On Tue, Sep 23, 2008 at 12:30 PM, Talpey, Thomas
<Thomas.Talpey@netapp.com> wrote:
> To be pedantic, identifiying this field as a "prot" may be just as
> misleading. For example "rdma" (which isn't mentioned btw ;-) )
> can employ tcp - iWARP adapters do this.

The Solaris mount_nfs man page puts it this way:

  proto=netid | rdma

Language for rdma support is yet to be added to nfs(5).

> I think instead that the proto= field simply names the "transport"
> rather than "netid" or "prot". Also, I think "prot" is much too easily
> mistaken for "port".

Was looking for a short word to use in the option's synopsis instead
of "netid" or "n".  How about "name" instead of "prot" ?

> So I suggest changing the example to "proto=transport", and deleting
> the word "protocol" in the text, simply leaving "the transport used by
> NFS to transmit..."

I don't have any objection to that.  Anyone else have an opinion?

> At 12:16 PM 9/23/2008, Chuck Lever wrote:
>>Mike Eisler noted that the use of the term "netid" in the descriptions
>>of the "proto=" option is not appropriate, since Linux does not allow
>>"udp6" or "tcp6".
>>
>>Remove the term "netid" from nfs(5).
>>
>>Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>---
>>
>> utils/mount/nfs.man |   12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>>diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
>>index 0fc5079..b1037a8 100644
>>--- a/utils/mount/nfs.man
>>+++ b/utils/mount/nfs.man
>>@@ -411,10 +411,10 @@ for mounting the
>> .B nfs
>> file system type.
>> .TP 1.5i
>>-.BI proto= netid
>>+.BI proto= prot
>> The transport protocol used by the NFS client
>> to transmit requests to the NFS server for this mount point.
>>-.I netid
>>+.I prot
>> can be either
>> .B udp
>> or
>>@@ -489,11 +489,11 @@ or the server's mountd service is not available
>>on the advertised port.
>> This option can be used when mounting an NFS server
>> through a firewall that blocks the rpcbind protocol.
>> .TP 1.5i
>>-.BI mountproto= netid
>>+.BI mountproto= prot
>> The transport protocol used by the NFS client
>> to transmit requests to the NFS server's mountd service when performing
>> this mount request, and when later unmounting this mount point.
>>-.I netid
>>+.I prot
>> can be either
>> .B udp
>> or
>>@@ -638,10 +638,10 @@ for mounting the
>> .B nfs4
>> file system type.
>> .TP 1.5i
>>-.BI proto= netid
>>+.BI proto= prot
>> The transport protocol used by the NFS client
>> to transmit requests to the NFS server for this mount point.
>>-.I netid
>>+.I prot
>> can be either
>> .B udp
>> or
>>
>>--
>>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

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Trond Myklebust]

On Tue, 2008-09-23 at 12:16 -0400, Chuck Lever wrote:
> Mike Eisler noted that the use of the term "netid" in the descriptions
> of the "proto=" option is not appropriate, since Linux does not allow
> "udp6" or "tcp6".

Why is it too late to add udp6/tcp6?

Cheers
  Trond

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Chuck Lever]

On Tue, Sep 23, 2008 at 12:56 PM, Trond Myklebust
<trond.myklebust@fys.uio.no> wrote:
> On Tue, 2008-09-23 at 12:16 -0400, Chuck Lever wrote:
>> Mike Eisler noted that the use of the term "netid" in the descriptions
>> of the "proto=" option is not appropriate, since Linux does not allow
>> "udp6" or "tcp6".
>
> Why is it too late to add udp6/tcp6?

It's not.  We could certainly introduce this as part of IPv6 support.
But I'm not sure we want to add it.  No-one has asked for it, except
for Mike.  I don't find it especially practical to have to change
"udp" to "udp6" on clients if the server is changed from IPv4 to IPv6
addressing.

But it *is* too late for 2.6.28 at this point.  We would need to
retrofit the NFS mount option parser, and do something clever for the
kernel's rpcbind client when it is stuck using only portmap.  Plus,
the RDMA client-side transport plays fast and loose with the xprt's
prot field so it can get TCP for NLM traffic.  I tried pulling that
chain once before, and it's going to take some careful thought.

Then all of this would need lots of testing.

So we wouldn't see this feature until next March at the earliest.
Right now, the documentation doesn't reflect the behavior of the
*existing* code base, which treats these as transports, not netids.

-- 
Chuck Lever

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Talpey, Thomas]

At 01:11 PM 9/23/2008, Chuck Lever wrote:
>kernel's rpcbind client when it is stuck using only portmap.  Plus,
>the RDMA client-side transport plays fast and loose with the xprt's
>prot field so it can get TCP for NLM traffic.  I tried pulling that
>chain once before, and it's going to take some careful thought.

I have no issue fixing that, if there's a better way. The only goal
of the chain-pulling is to redirect the side protocols to UDP/TCP,
much like the "mountproto=" option does. NLM, as you mention,
is the tricky one, since it literally reaches into the NFS clnt struct
and "borrows" the transport identifier by value.

Tom.

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Chuck Lever]

On Tue, Sep 23, 2008 at 3:04 PM, Talpey, Thomas
<Thomas.Talpey@netapp.com> wrote:
> At 01:11 PM 9/23/2008, Chuck Lever wrote:
>>kernel's rpcbind client when it is stuck using only portmap.  Plus,
>>the RDMA client-side transport plays fast and loose with the xprt's
>>prot field so it can get TCP for NLM traffic.  I tried pulling that
>>chain once before, and it's going to take some careful thought.
>
> I have no issue fixing that, if there's a better way. The only goal
> of the chain-pulling is to redirect the side protocols to UDP/TCP,
> much like the "mountproto=" option does. NLM, as you mention,
> is the tricky one, since it literally reaches into the NFS clnt struct
> and "borrows" the transport identifier by value.

Yup, that's the sticky part.

--
Chuck Lever

Re: [PATCH 1/2] nfs(5): Replace the term "netid" in mount option descriptions

[Steve Dickson]

Chuck Lever wrote:
> Mike Eisler noted that the use of the term "netid" in the descriptions
> of the "proto=" option is not appropriate, since Linux does not allow
> "udp6" or "tcp6".
> 
> Remove the term "netid" from nfs(5).
Committed... using the word "transport" instead of "prot" as suggested by Tom.

steved.