PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

[Neil Brown]

Otherwise if you cannot stop and restart nfsd while a client holds a
connection.  Why this isn't the default I cannot imagine...

 ----------- Diffstat output ------------
 ./net/sunrpc/svcsock.c |    1 +
 1 files changed, 1 insertion(+)

--- ./net/sunrpc/svcsock.c	2002/08/12 06:01:42	1.2
+++ ./net/sunrpc/svcsock.c	2002/08/13 01:54:39	1.3
@@ -1208,6 +1208,7 @@ svc_create_socket(struct svc_serv *serv,
 		return error;
 
 	if (sin != NULL) {
+		sock->sk->reuse = 1; /* allow address reuse */
 		error = sock->ops->bind(sock, (struct sockaddr *) sin,
 						sizeof(*sin));
 		if (error < 0)


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

[Chuck Lever]

it's been suggested that the client should also try reusing the port
number when reconnecting over TCP... any thoughts on that?

On Tue, 13 Aug 2002, Neil Brown wrote:

>
> Otherwise if you cannot stop and restart nfsd while a client holds a
> connection.  Why this isn't the default I cannot imagine...
>
>  ----------- Diffstat output ------------
>  ./net/sunrpc/svcsock.c |    1 +
>  1 files changed, 1 insertion(+)
>
> --- ./net/sunrpc/svcsock.c	2002/08/12 06:01:42	1.2
> +++ ./net/sunrpc/svcsock.c	2002/08/13 01:54:39	1.3
> @@ -1208,6 +1208,7 @@ svc_create_socket(struct svc_serv *serv,
>  		return error;
>
>  	if (sin != NULL) {
> +		sock->sk->reuse = 1; /* allow address reuse */
>  		error = sock->ops->bind(sock, (struct sockaddr *) sin,
>  						sizeof(*sin));
>  		if (error < 0)
>

	- Chuck Lever
--
corporate:	<cel@netapp.com>
personal:	<chucklever@bigfoot.com>



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

[Neil Brown]

[ cc list trimmed ]
On Monday August 12, cel@citi.umich.edu wrote:
> it's been suggested that the client should also try reusing the port
> number when reconnecting over TCP... any thoughts on that?

Why?
You would not be able to reconnect until the TCP timeout on connection
re-use has passed, and by that time any benefit that you might gain is
probably lost.
How does the TCP timeout compare with the replay-cache timeout??

NeilBrown


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

[Julian Cowley]

On Tue, 13 Aug 2002, Neil Brown wrote:
> [ cc list trimmed ]
> On Monday August 12, cel@citi.umich.edu wrote:
> > it's been suggested that the client should also try reusing the port
> > number when reconnecting over TCP... any thoughts on that?
>
> Why?
> You would not be able to reconnect until the TCP timeout on connection
> re-use has passed, and by that time any benefit that you might gain is
> probably lost.
> How does the TCP timeout compare with the replay-cache timeout??

Just an aside here...

The last time I looked at NFS over TCP on Linux (maybe 6-12 months
ago?), there was a problem related to this.  With my test setup,
I required NFS clients to use a reserved port (the "secure" option
in mountd, although the server was acutally an OpenBSD machine).
After the server would reboot, the Linux client would reconnect,
but it would reconnect using a non-reserved port number even though
the original mount used a reserved port number.  This meant that the
mount would never come back up.

If the client used the same port number, at least it would reconnect in
this case.  A better solution would be to have it keep track of whether
a reserved port was required for the mount or not.



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: PATCH - RPC/TCP 2 of 4 - Allow SO_REUSEADDR for NFS sockets

[Trond Myklebust]

>>>>> " " == Neil Brown <neilb@cse.unsw.edu.au> writes:

    >> it's been suggested that the client should also try reusing the
    >> port number when reconnecting over TCP... any thoughts on that?

     > Why?  You would not be able to reconnect until the TCP timeout
     > on connection re-use has passed, and by that time any benefit
     > that you might gain is probably lost.  How does the TCP timeout
     > compare with the replay-cache timeout??

The connection may break for other reasons (network partition for
instance). Reusing the port number guarantees that the replay cache
works as expected.

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs