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 <[email protected]>
---
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 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 <[email protected]>
>---
>
> 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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 23, 2008 at 12:30 PM, Talpey, Thomas
<[email protected]> 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 <[email protected]>
>>---
>>
>> 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 [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, 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
On Tue, Sep 23, 2008 at 12:56 PM, Trond Myklebust
<[email protected]> 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
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.
On Tue, Sep 23, 2008 at 3:04 PM, Talpey, Thomas
<[email protected]> 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