Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
@ 2020-01-16 19:08 Olga Kornievskaia
  2020-01-17 21:09 ` Schumaker, Anna
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Olga Kornievskaia @ 2020-01-16 19:08 UTC (permalink / raw)
  To: trond.myklebust, anna.schumaker; +Cc: linux-nfs

From: Olga Kornievskaia <kolga@netapp.com>

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
---
 fs/nfs/nfs4client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 460d625..4df3fb0 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server *server,
 
 	if (minorversion == 0)
 		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
-	else if (proto == XPRT_TRANSPORT_TCP)
+	if (proto == XPRT_TRANSPORT_TCP)
 		cl_init.nconnect = nconnect;
 
 	if (server->flags & NFS_MOUNT_NORESVPORT)
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-16 19:08 [PATCH 1/1] NFSv4.0 allow nconnect for v4.0 Olga Kornievskaia
@ 2020-01-17 21:09 ` Schumaker, Anna
  2020-01-17 21:14   ` Trond Myklebust
  2020-01-20 15:35 ` [PATCH 1/1] " Steve Dickson
  2020-01-31 19:56 ` Olga Kornievskaia
  2 siblings, 1 reply; 14+ messages in thread
From: Schumaker, Anna @ 2020-01-17 21:09 UTC (permalink / raw)
  To: olga.kornievskaia, trond.myklebust; +Cc: linux-nfs

Hi Olga,

On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> From: Olga Kornievskaia <kolga@netapp.com>

Have you done any testing with nconnect and the v4.0 replay caches? I did some
digging on the mailing list and found this in one of the cover letters from
Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now; I don't
feel comfortable subjecting NFSv3/v4 replay caches to this treatment yet."

Thanks,
Anna

> 
> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> ---
>  fs/nfs/nfs4client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> index 460d625..4df3fb0 100644
> --- a/fs/nfs/nfs4client.c
> +++ b/fs/nfs/nfs4client.c
> @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server *server,
>  
>  	if (minorversion == 0)
>  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> -	else if (proto == XPRT_TRANSPORT_TCP)
> +	if (proto == XPRT_TRANSPORT_TCP)
>  		cl_init.nconnect = nconnect;
>  
>  	if (server->flags & NFS_MOUNT_NORESVPORT)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-17 21:09 ` Schumaker, Anna
@ 2020-01-17 21:14   ` Trond Myklebust
  2020-01-17 21:16     ` Schumaker, Anna
  0 siblings, 1 reply; 14+ messages in thread
From: Trond Myklebust @ 2020-01-17 21:14 UTC (permalink / raw)
  To: Anna.Schumaker, olga.kornievskaia; +Cc: linux-nfs

On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
> Hi Olga,
> 
> On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> > From: Olga Kornievskaia <kolga@netapp.com>
> 
> Have you done any testing with nconnect and the v4.0 replay caches? I
> did some
> digging on the mailing list and found this in one of the cover
> letters from
> Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
> I don't
> feel comfortable subjecting NFSv3/v4 replay caches to this treatment
> yet."
> 

That comment should be considered obsolete. The current code works hard
to ensure that we replay using the same connection (or at least the
same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
For that reason we've had NFSv3 support since the feature was merged.
The NFSv4.0 support was just forgotten.

> Thanks,
> Anna
> 
> > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > ---
> >  fs/nfs/nfs4client.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > index 460d625..4df3fb0 100644
> > --- a/fs/nfs/nfs4client.c
> > +++ b/fs/nfs/nfs4client.c
> > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > *server,
> >  
> >  	if (minorversion == 0)
> >  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > -	else if (proto == XPRT_TRANSPORT_TCP)
> > +	if (proto == XPRT_TRANSPORT_TCP)
> >  		cl_init.nconnect = nconnect;
> >  
> >  	if (server->flags & NFS_MOUNT_NORESVPORT)
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-17 21:14   ` Trond Myklebust
@ 2020-01-17 21:16     ` Schumaker, Anna
  2020-06-11 20:09       ` J. Bruce Fields
  0 siblings, 1 reply; 14+ messages in thread
From: Schumaker, Anna @ 2020-01-17 21:16 UTC (permalink / raw)
  To: olga.kornievskaia, trondmy; +Cc: linux-nfs

On Fri, 2020-01-17 at 21:14 +0000, Trond Myklebust wrote:
> On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
> > Hi Olga,
> > 
> > On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> > > From: Olga Kornievskaia <kolga@netapp.com>
> > 
> > Have you done any testing with nconnect and the v4.0 replay caches? I
> > did some
> > digging on the mailing list and found this in one of the cover
> > letters from
> > Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
> > I don't
> > feel comfortable subjecting NFSv3/v4 replay caches to this treatment
> > yet."
> > 
> 
> That comment should be considered obsolete. The current code works hard
> to ensure that we replay using the same connection (or at least the
> same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
> For that reason we've had NFSv3 support since the feature was merged.
> The NFSv4.0 support was just forgotten.

Thanks for the explanation! I'll add the patch.

Anna

> 
> > Thanks,
> > Anna
> > 
> > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > ---
> > >  fs/nfs/nfs4client.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > index 460d625..4df3fb0 100644
> > > --- a/fs/nfs/nfs4client.c
> > > +++ b/fs/nfs/nfs4client.c
> > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > > *server,
> > >  
> > >  	if (minorversion == 0)
> > >  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > > -	else if (proto == XPRT_TRANSPORT_TCP)
> > > +	if (proto == XPRT_TRANSPORT_TCP)
> > >  		cl_init.nconnect = nconnect;
> > >  
> > >  	if (server->flags & NFS_MOUNT_NORESVPORT)
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
> 
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-16 19:08 [PATCH 1/1] NFSv4.0 allow nconnect for v4.0 Olga Kornievskaia
  2020-01-17 21:09 ` Schumaker, Anna
@ 2020-01-20 15:35 ` Steve Dickson
  2020-01-23  0:23   ` Trond Myklebust
  2020-01-31 19:56 ` Olga Kornievskaia
  2 siblings, 1 reply; 14+ messages in thread
From: Steve Dickson @ 2020-01-20 15:35 UTC (permalink / raw)
  To: Olga Kornievskaia, trond.myklebust, anna.schumaker; +Cc: linux-nfs

Hello,

On 1/16/20 2:08 PM, Olga Kornievskaia wrote:
> From: Olga Kornievskaia <kolga@netapp.com>
> 
> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> ---
>  fs/nfs/nfs4client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> index 460d625..4df3fb0 100644
> --- a/fs/nfs/nfs4client.c
> +++ b/fs/nfs/nfs4client.c
> @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server *server,
>  
>  	if (minorversion == 0)
>  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> -	else if (proto == XPRT_TRANSPORT_TCP)
> +	if (proto == XPRT_TRANSPORT_TCP)
>  		cl_init.nconnect = nconnect;
>  
>  	if (server->flags & NFS_MOUNT_NORESVPORT)
> 
Tested-by: Steve Dickson <steved@redhat.com>

With this patch v4.0 mounts act just like v4.1/v4.2 mounts
But is that a good thing. :-)  

Here is what I've found in my testing...

mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp

Will create 12 TCP connections and maintain those 12 
connections until the umount happens. By maintain I mean 
if the connection times out, it is reconnected 
to maintain the 12 connections 

# mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
# netstat -an | grep 172.31.1.54 | wc -l
12
# netstat -an | grep 172.31.1.54        
tcp        0      0 172.31.1.24:901         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:667         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:746         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:672         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:832         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:895         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:673         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:732         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:795         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:918         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:674         172.31.1.54:2049        ESTABLISHED
tcp        0      0 172.31.1.24:953         172.31.1.54:2049        ESTABLISHED

# umount /mnt/tmp
# netstat -an | grep 172.31.1.54 | wc -l
12
# netstat -an | grep 172.31.1.54
tcp        0      0 172.31.1.24:901         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:667         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:746         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:672         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:832         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:895         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:673         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:732         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:795         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:918         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:674         172.31.1.54:2049        TIME_WAIT  
tcp        0      0 172.31.1.24:953         172.31.1.54:2049        TIME_WAIT 

Is this the expected behavior? 

If so I have a few concerns...

* The connections walk all over the /etc/services namespace. Meaning
using ports that are reserved for registered services, something
we've tried to avoid in userland by not binding to privilege ports and
use of backlist ports via /etc/bindresvport.blacklist

* When the unmount happens, all those connections go into TIME_WAIT on 
privilege ports and there are only so many of those. Not good during mount 
storms (when a server reboots and thousand of home dirs are remounted).

* No man page describing the new feature.

I realize there is not much we can do about some of these
(aka umount==>TIME_WAIT) but I think we need to document 
what we are doing to people's connection namespace when 
they use this feature. 

steved.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-20 15:35 ` [PATCH 1/1] " Steve Dickson
@ 2020-01-23  0:23   ` Trond Myklebust
  2020-01-27 18:39     ` Steve Dickson
  0 siblings, 1 reply; 14+ messages in thread
From: Trond Myklebust @ 2020-01-23  0:23 UTC (permalink / raw)
  To: SteveD, olga.kornievskaia, anna.schumaker; +Cc: linux-nfs

On Mon, 2020-01-20 at 10:35 -0500, Steve Dickson wrote:
> Hello,
> 
> On 1/16/20 2:08 PM, Olga Kornievskaia wrote:
> > From: Olga Kornievskaia <kolga@netapp.com>
> > 
> > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > ---
> >  fs/nfs/nfs4client.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > index 460d625..4df3fb0 100644
> > --- a/fs/nfs/nfs4client.c
> > +++ b/fs/nfs/nfs4client.c
> > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > *server,
> >  
> >  	if (minorversion == 0)
> >  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > -	else if (proto == XPRT_TRANSPORT_TCP)
> > +	if (proto == XPRT_TRANSPORT_TCP)
> >  		cl_init.nconnect = nconnect;
> >  
> >  	if (server->flags & NFS_MOUNT_NORESVPORT)
> > 
> Tested-by: Steve Dickson <steved@redhat.com>
> 
> With this patch v4.0 mounts act just like v4.1/v4.2 mounts
> But is that a good thing. :-)  
> 
> Here is what I've found in my testing...
> 
> mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
> 
> Will create 12 TCP connections and maintain those 12 
> connections until the umount happens. By maintain I mean 
> if the connection times out, it is reconnected 
> to maintain the 12 connections 
> 
> # mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
> # netstat -an | grep 172.31.1.54 | wc -l
> 12
> # netstat -an | grep 172.31.1.54        
> tcp        0      0
> 172.31.1.24:901         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:667         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:746         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:672         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:832         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:895         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:673         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:732         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:795         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:918         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:674         172.31.1.54:2049        ESTABLISHED
> tcp        0      0
> 172.31.1.24:953         172.31.1.54:2049        ESTABLISHED
> 
> # umount /mnt/tmp
> # netstat -an | grep 172.31.1.54 | wc -l
> 12
> # netstat -an | grep 172.31.1.54
> tcp        0      0
> 172.31.1.24:901         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:667         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:746         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:672         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:832         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:895         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:673         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:732         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:795         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:918         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:674         172.31.1.54:2049        TIME_WAIT  
> tcp        0      0
> 172.31.1.24:953         172.31.1.54:2049        TIME_WAIT 
> 
> Is this the expected behavior? 
> 
> If so I have a few concerns...
> 
> * The connections walk all over the /etc/services namespace. Meaning
> using ports that are reserved for registered services, something
> we've tried to avoid in userland by not binding to privilege ports
> and
> use of backlist ports via /etc/bindresvport.blacklist
> 
> * When the unmount happens, all those connections go into TIME_WAIT
> on 
> privilege ports and there are only so many of those. Not good during
> mount 
> storms (when a server reboots and thousand of home dirs are
> remounted).
> 
> * No man page describing the new feature.
> 
> I realize there is not much we can do about some of these
> (aka umount==>TIME_WAIT) but I think we need to document 
> what we are doing to people's connection namespace when 
> they use this feature. 

I'm not sure that I understand the concern. The connections are limited
to a specific window of ports by the min_resvport/max_resvport sunrpc
module parameters just as they were before we added 'nconnect'. Nothing
has changed in the way we choose ports...

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-23  0:23   ` Trond Myklebust
@ 2020-01-27 18:39     ` Steve Dickson
  2020-01-27 19:35       ` Trond Myklebust
  0 siblings, 1 reply; 14+ messages in thread
From: Steve Dickson @ 2020-01-27 18:39 UTC (permalink / raw)
  To: Trond Myklebust, olga.kornievskaia, anna.schumaker; +Cc: linux-nfs



On 1/22/20 7:23 PM, Trond Myklebust wrote:
> On Mon, 2020-01-20 at 10:35 -0500, Steve Dickson wrote:
>> Hello,
>>
>> On 1/16/20 2:08 PM, Olga Kornievskaia wrote:
>>> From: Olga Kornievskaia <kolga@netapp.com>
>>>
>>> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
>>> ---
>>>  fs/nfs/nfs4client.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
>>> index 460d625..4df3fb0 100644
>>> --- a/fs/nfs/nfs4client.c
>>> +++ b/fs/nfs/nfs4client.c
>>> @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
>>> *server,
>>>  
>>>  	if (minorversion == 0)
>>>  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
>>> -	else if (proto == XPRT_TRANSPORT_TCP)
>>> +	if (proto == XPRT_TRANSPORT_TCP)
>>>  		cl_init.nconnect = nconnect;
>>>  
>>>  	if (server->flags & NFS_MOUNT_NORESVPORT)
>>>
>> Tested-by: Steve Dickson <steved@redhat.com>
>>
>> With this patch v4.0 mounts act just like v4.1/v4.2 mounts
>> But is that a good thing. :-)  
>>
>> Here is what I've found in my testing...
>>
>> mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
>>
>> Will create 12 TCP connections and maintain those 12 
>> connections until the umount happens. By maintain I mean 
>> if the connection times out, it is reconnected 
>> to maintain the 12 connections 
>>
>> # mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
>> # netstat -an | grep 172.31.1.54 | wc -l
>> 12
>> # netstat -an | grep 172.31.1.54        
>> tcp        0      0
>> 172.31.1.24:901         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:667         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:746         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:672         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:832         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:895         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:673         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:732         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:795         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:918         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:674         172.31.1.54:2049        ESTABLISHED
>> tcp        0      0
>> 172.31.1.24:953         172.31.1.54:2049        ESTABLISHED
>>
>> # umount /mnt/tmp
>> # netstat -an | grep 172.31.1.54 | wc -l
>> 12
>> # netstat -an | grep 172.31.1.54
>> tcp        0      0
>> 172.31.1.24:901         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:667         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:746         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:672         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:832         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:895         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:673         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:732         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:795         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:918         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:674         172.31.1.54:2049        TIME_WAIT  
>> tcp        0      0
>> 172.31.1.24:953         172.31.1.54:2049        TIME_WAIT 
>>
>> Is this the expected behavior? 
>>
>> If so I have a few concerns...
>>
>> * The connections walk all over the /etc/services namespace. Meaning
>> using ports that are reserved for registered services, something
>> we've tried to avoid in userland by not binding to privilege ports
>> and
>> use of backlist ports via /etc/bindresvport.blacklist
>>
>> * When the unmount happens, all those connections go into TIME_WAIT
>> on 
>> privilege ports and there are only so many of those. Not good during
>> mount 
>> storms (when a server reboots and thousand of home dirs are
>> remounted).
>>
>> * No man page describing the new feature.
>>
>> I realize there is not much we can do about some of these
>> (aka umount==>TIME_WAIT) but I think we need to document 
>> what we are doing to people's connection namespace when 
>> they use this feature. 
> 
> I'm not sure that I understand the concern. The connections are limited
> to a specific window of ports by the min_resvport/max_resvport sunrpc
> module parameters just as they were before we added 'nconnect'. Nothing
> has changed in the way we choose ports...
> 
Maybe this problem has existed for a while... 

Here are the mins/max ports
RPC_DEF_MIN_RESVPORT    (665U)
RPC_DEF_MAX_RESVPORT    (1023U)

From /etc/services there are the services in that range
acp(674), ha-cluster(694), kerberos-adm(749), kerberos-iv(750)
webster(765), phonebook(767), rsync(873), rquotad(875), 
telnets(992), imaps(993), pop3s(995)

Granted a lot of these are unused/legacy services, but some of
them, like imaps and rsync, are still used. 

My point is since the nconnect connections are persistent, for
the life of the mount, we could end up squatting on ports other
services will needed.

Maybe there is not much we can do about this... But we should explain
somewhere, like the man page, that nconnect will create up to 16
persistent connection on register privilege ports.

steved.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-27 18:39     ` Steve Dickson
@ 2020-01-27 19:35       ` Trond Myklebust
  0 siblings, 0 replies; 14+ messages in thread
From: Trond Myklebust @ 2020-01-27 19:35 UTC (permalink / raw)
  To: SteveD, olga.kornievskaia, anna.schumaker; +Cc: linux-nfs

On Mon, 2020-01-27 at 13:39 -0500, Steve Dickson wrote:
> 
> On 1/22/20 7:23 PM, Trond Myklebust wrote:
> > On Mon, 2020-01-20 at 10:35 -0500, Steve Dickson wrote:
> > > Hello,
> > > 
> > > On 1/16/20 2:08 PM, Olga Kornievskaia wrote:
> > > > From: Olga Kornievskaia <kolga@netapp.com>
> > > > 
> > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > ---
> > > >  fs/nfs/nfs4client.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > > index 460d625..4df3fb0 100644
> > > > --- a/fs/nfs/nfs4client.c
> > > > +++ b/fs/nfs/nfs4client.c
> > > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct
> > > > nfs_server
> > > > *server,
> > > >  
> > > >  	if (minorversion == 0)
> > > >  		__set_bit(NFS_CS_REUSEPORT,
> > > > &cl_init.init_flags);
> > > > -	else if (proto == XPRT_TRANSPORT_TCP)
> > > > +	if (proto == XPRT_TRANSPORT_TCP)
> > > >  		cl_init.nconnect = nconnect;
> > > >  
> > > >  	if (server->flags & NFS_MOUNT_NORESVPORT)
> > > > 
> > > Tested-by: Steve Dickson <steved@redhat.com>
> > > 
> > > With this patch v4.0 mounts act just like v4.1/v4.2 mounts
> > > But is that a good thing. :-)  
> > > 
> > > Here is what I've found in my testing...
> > > 
> > > mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
> > > 
> > > Will create 12 TCP connections and maintain those 12 
> > > connections until the umount happens. By maintain I mean 
> > > if the connection times out, it is reconnected 
> > > to maintain the 12 connections 
> > > 
> > > # mount -onconnect=12 172.31.1.54:/home/tmp /mnt/tmp
> > > # netstat -an | grep 172.31.1.54 | wc -l
> > > 12
> > > # netstat -an | grep 172.31.1.54        
> > > tcp        0      0
> > > 172.31.1.24:901         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:667         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:746         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:672         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:832         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:895         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:673         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:732         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:795         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:918         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:674         172.31.1.54:2049        ESTABLISHED
> > > tcp        0      0
> > > 172.31.1.24:953         172.31.1.54:2049        ESTABLISHED
> > > 
> > > # umount /mnt/tmp
> > > # netstat -an | grep 172.31.1.54 | wc -l
> > > 12
> > > # netstat -an | grep 172.31.1.54
> > > tcp        0      0
> > > 172.31.1.24:901         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:667         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:746         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:672         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:832         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:895         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:673         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:732         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:795         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:918         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:674         172.31.1.54:2049        TIME_WAIT  
> > > tcp        0      0
> > > 172.31.1.24:953         172.31.1.54:2049        TIME_WAIT 
> > > 
> > > Is this the expected behavior? 
> > > 
> > > If so I have a few concerns...
> > > 
> > > * The connections walk all over the /etc/services namespace.
> > > Meaning
> > > using ports that are reserved for registered services, something
> > > we've tried to avoid in userland by not binding to privilege
> > > ports
> > > and
> > > use of backlist ports via /etc/bindresvport.blacklist
> > > 
> > > * When the unmount happens, all those connections go into
> > > TIME_WAIT
> > > on 
> > > privilege ports and there are only so many of those. Not good
> > > during
> > > mount 
> > > storms (when a server reboots and thousand of home dirs are
> > > remounted).
> > > 
> > > * No man page describing the new feature.
> > > 
> > > I realize there is not much we can do about some of these
> > > (aka umount==>TIME_WAIT) but I think we need to document 
> > > what we are doing to people's connection namespace when 
> > > they use this feature. 
> > 
> > I'm not sure that I understand the concern. The connections are
> > limited
> > to a specific window of ports by the min_resvport/max_resvport
> > sunrpc
> > module parameters just as they were before we added 'nconnect'.
> > Nothing
> > has changed in the way we choose ports...
> > 
> Maybe this problem has existed for a while... 
> 
> Here are the mins/max ports
> RPC_DEF_MIN_RESVPORT    (665U)
> RPC_DEF_MAX_RESVPORT    (1023U)
> 
> From /etc/services there are the services in that range
> acp(674), ha-cluster(694), kerberos-adm(749), kerberos-iv(750)
> webster(765), phonebook(767), rsync(873), rquotad(875), 
> telnets(992), imaps(993), pop3s(995)
> 
> Granted a lot of these are unused/legacy services, but some of
> them, like imaps and rsync, are still used. 
> 
> My point is since the nconnect connections are persistent, for
> the life of the mount, we could end up squatting on ports other
> services will needed.
> 
> Maybe there is not much we can do about this... But we should explain
> somewhere, like the man page, that nconnect will create up to 16
> persistent connection on register privilege ports.


If users have a need to run servers on a port that might chosen by a
kernel nfs, lockd or rpcbind client, then they can guarantee no
collisions by redefining the 'privileged ports' available to sunrpc to
any arbitrary range <portnr1> - <portnr2>:

Either

 * Reserve the ports at module load time, by adding a line to a config
   file /etc/modprobe.d/foo.conf of the form
      options sunrpc min_resvport=<portnr1> max_resvport=<portnr2>

or

 * Change the port reservation after module load (but before mounting
   your first NFS filesystem) using
      echo '<portnr1>' > /sys/module/sunrpc/parameters/min_resvport
      echo '<portnr2>' > /sys/module/sunrpc/parameters/max_resvport

This is something users ought to be doing already if they need
guaranteed availability of specific ports in the range 665-1023 while
using the NFS client. That is entirely independent of whether or not
they are using nconnect.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-16 19:08 [PATCH 1/1] NFSv4.0 allow nconnect for v4.0 Olga Kornievskaia
  2020-01-17 21:09 ` Schumaker, Anna
  2020-01-20 15:35 ` [PATCH 1/1] " Steve Dickson
@ 2020-01-31 19:56 ` Olga Kornievskaia
  2 siblings, 0 replies; 14+ messages in thread
From: Olga Kornievskaia @ 2020-01-31 19:56 UTC (permalink / raw)
  To: Trond Myklebust, Anna Schumaker; +Cc: linux-nfs

Trond, Anna,

If it's not too late then I'd like to re-tract this patch. I
understand if somebody else would really like to have this
functionality in then please speak up. If it's too late to pull I also
understand but I need to at least try.

Thank you.

On Thu, Jan 16, 2020 at 2:09 PM Olga Kornievskaia
<olga.kornievskaia@gmail.com> wrote:
>
> From: Olga Kornievskaia <kolga@netapp.com>
>
> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> ---
>  fs/nfs/nfs4client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> index 460d625..4df3fb0 100644
> --- a/fs/nfs/nfs4client.c
> +++ b/fs/nfs/nfs4client.c
> @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server *server,
>
>         if (minorversion == 0)
>                 __set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> -       else if (proto == XPRT_TRANSPORT_TCP)
> +       if (proto == XPRT_TRANSPORT_TCP)
>                 cl_init.nconnect = nconnect;
>
>         if (server->flags & NFS_MOUNT_NORESVPORT)
> --
> 1.8.3.1
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-01-17 21:16     ` Schumaker, Anna
@ 2020-06-11 20:09       ` J. Bruce Fields
  2020-06-11 22:46         ` Rick Macklem
                           ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: J. Bruce Fields @ 2020-06-11 20:09 UTC (permalink / raw)
  To: Schumaker, Anna; +Cc: olga.kornievskaia, trondmy, linux-nfs, steved

On Fri, Jan 17, 2020 at 09:16:54PM +0000, Schumaker, Anna wrote:
> On Fri, 2020-01-17 at 21:14 +0000, Trond Myklebust wrote:
> > On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
> > > Hi Olga,
> > > 
> > > On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> > > > From: Olga Kornievskaia <kolga@netapp.com>
> > > 
> > > Have you done any testing with nconnect and the v4.0 replay caches? I
> > > did some
> > > digging on the mailing list and found this in one of the cover
> > > letters from
> > > Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
> > > I don't
> > > feel comfortable subjecting NFSv3/v4 replay caches to this treatment
> > > yet."
> > > 
> > 
> > That comment should be considered obsolete. The current code works hard
> > to ensure that we replay using the same connection (or at least the
> > same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
> > For that reason we've had NFSv3 support since the feature was merged.
> > The NFSv4.0 support was just forgotten.
> 
> Thanks for the explanation! I'll add the patch.

What happened to this patch?  As far as I can tell, the conclusion of
this thread was that it should be applied.

--b.

> 
> Anna
> 
> > 
> > > Thanks,
> > > Anna
> > > 
> > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > ---
> > > >  fs/nfs/nfs4client.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > > index 460d625..4df3fb0 100644
> > > > --- a/fs/nfs/nfs4client.c
> > > > +++ b/fs/nfs/nfs4client.c
> > > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > > > *server,
> > > >  
> > > >  	if (minorversion == 0)
> > > >  		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > > > -	else if (proto == XPRT_TRANSPORT_TCP)
> > > > +	if (proto == XPRT_TRANSPORT_TCP)
> > > >  		cl_init.nconnect = nconnect;
> > > >  
> > > >  	if (server->flags & NFS_MOUNT_NORESVPORT)
> > -- 
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > trond.myklebust@hammerspace.com
> > 
> > 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-06-11 20:09       ` J. Bruce Fields
@ 2020-06-11 22:46         ` Rick Macklem
  2020-06-11 23:00         ` Rick Macklem
  2020-06-12 13:26         ` Olga Kornievskaia
  2 siblings, 0 replies; 14+ messages in thread
From: Rick Macklem @ 2020-06-11 22:46 UTC (permalink / raw)
  To: J. Bruce Fields, Schumaker, Anna
  Cc: olga.kornievskaia, trondmy, linux-nfs, steved


________________________________________
From: linux-nfs-owner@vger.kernel.org <linux-nfs-owner@vger.kernel.org> on behalf of J. Bruce Fields <bfields@fieldses.org>
Sent: Thursday, June 11, 2020 4:09 PM
To: Schumaker, Anna
Cc: olga.kornievskaia@gmail.com; trondmy@hammerspace.com; linux-nfs@vger.kernel.org; steved@redhat.com
Subject: Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


On Fri, Jan 17, 2020 at 09:16:54PM +0000, Schumaker, Anna wrote:
> On Fri, 2020-01-17 at 21:14 +0000, Trond Myklebust wrote:
> > On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
> > > Hi Olga,
> > >
> > > On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> > > > From: Olga Kornievskaia <kolga@netapp.com>
> > >
> > > Have you done any testing with nconnect and the v4.0 replay caches? I
> > > did some
> > > digging on the mailing list and found this in one of the cover
> > > letters from
> > > Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
> > > I don't
> > > feel comfortable subjecting NFSv3/v4 replay caches to this treatment
> > > yet."
> > >
> >
> > That comment should be considered obsolete. The current code works hard
> > to ensure that we replay using the same connection (or at least the
> > same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
> > For that reason we've had NFSv3 support since the feature was merged.
> > The NFSv4.0 support was just forgotten.
>
> Thanks for the explanation! I'll add the patch.

What happened to this patch?  As far as I can tell, the conclusion of
this thread was that it should be applied.

--b.

>
> Anna
>
> >
> > > Thanks,
> > > Anna
> > >
> > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > ---
> > > >  fs/nfs/nfs4client.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > > index 460d625..4df3fb0 100644
> > > > --- a/fs/nfs/nfs4client.c
> > > > +++ b/fs/nfs/nfs4client.c
> > > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > > > *server,
> > > >
> > > >         if (minorversion == 0)
> > > >                 __set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > > > -       else if (proto == XPRT_TRANSPORT_TCP)
> > > > +       if (proto == XPRT_TRANSPORT_TCP)
> > > >                 cl_init.nconnect = nconnect;
> > > >
> > > >         if (server->flags & NFS_MOUNT_NORESVPORT)
> > --
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > trond.myklebust@hammerspace.com
> >
> >


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-06-11 20:09       ` J. Bruce Fields
  2020-06-11 22:46         ` Rick Macklem
@ 2020-06-11 23:00         ` Rick Macklem
  2020-06-12 13:26         ` Olga Kornievskaia
  2 siblings, 0 replies; 14+ messages in thread
From: Rick Macklem @ 2020-06-11 23:00 UTC (permalink / raw)
  To: J. Bruce Fields, Schumaker, Anna
  Cc: olga.kornievskaia, trondmy, linux-nfs, steved

J. Bruce Fields wrote:
>On Fri, Jan 17, 2020 at 09:16:54PM +0000, Schumaker, Anna wrote:
>> On Fri, 2020-01-17 at 21:14 +0000, Trond Myklebust wrote:
>> > On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
>> > > Hi Olga,
>> > >
>> > > On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
>> > > > From: Olga Kornievskaia <kolga@netapp.com>
>> > >
>> > > Have you done any testing with nconnect and the v4.0 replay caches? I
>> > > did some
>> > > digging on the mailing list and found this in one of the cover
>> > > letters from
>> > > Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
>> > > I don't
>> > > feel comfortable subjecting NFSv3/v4 replay caches to this treatment
>> > > yet."
>> > >
>> >
>> > That comment should be considered obsolete. The current code works hard
>> > to ensure that we replay using the same connection (or at least the
>> > same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
>> > For that reason we've had NFSv3 support since the feature was merged.
>> > The NFSv4.0 support was just forgotten.
>>
>> Thanks for the explanation! I'll add the patch.
Maybe I am misinterpreting this discussion and, if so, please just ignore these
comments.
Here are two snippets from RFC7530:
In Sec. 3.1.
   Where an NFSv4 implementation supports operation over the IP network
   protocol, the supported transport layer between NFS and IP MUST be an
   IETF standardized transport protocol that is specified to avoid
   network congestion; such transports include TCP and the Stream
   Control Transmission Protocol (SCTP).  To enhance the possibilities
   for interoperability, an NFSv4 implementation MUST support operation
   over the TCP transport protocol.

This clearly states that NFSv4.0 cannot operate over UDP. (See the MUST above.)

In Sec. 3.1.1.
   When processing an NFSv4 request received over a reliable transport
   such as TCP, the NFSv4 server MUST NOT silently drop the request,
   except if the established transport connection has been broken.
   Given such a contract between NFSv4 clients and servers, clients MUST
   NOT retry a request unless one or both of the following are true:

   o  The transport connection has been broken

   o  The procedure being retried is the NULL procedure
If the TCP connection is broken, making a new TCP connection on the
same port #s would be risky, unless a long delay is done. Normally a
different port# would be used and the implication of the above is that
any retry of an RPC (above the TCP layer retransmits of segments)
will normally be from a different port#.

Long ago I played around with a DRC for TCP (which ended up in FreeBSD)
and because retries happen after a long timeout and there can be many
other RPCs done in between the first attempt for the RPC and a subsequent
retry of the RPC, the design must be very different than a DRC for UDP.
--> LRU caching doesn't work well unless the cache size is very large.
--> For NFSv4.0 over TCP (not NFSv3), the DRC must assume (or at least
      handle) retries from a different client port#, since they will be done on
      a different TCP connection and that will almost inevitably imply a
      different port#.

rick

What happened to this patch?  As far as I can tell, the conclusion of
this thread was that it should be applied.

--b.

>
> Anna
>
> >
> > > Thanks,
> > > Anna
> > >
> > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > ---
> > > >  fs/nfs/nfs4client.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > > index 460d625..4df3fb0 100644
> > > > --- a/fs/nfs/nfs4client.c
> > > > +++ b/fs/nfs/nfs4client.c
> > > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > > > *server,
> > > >
> > > >         if (minorversion == 0)
> > > >                 __set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > > > -       else if (proto == XPRT_TRANSPORT_TCP)
> > > > +       if (proto == XPRT_TRANSPORT_TCP)
> > > >                 cl_init.nconnect = nconnect;
> > > >
> > > >         if (server->flags & NFS_MOUNT_NORESVPORT)
> > --
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > trond.myklebust@hammerspace.com
> >
> >


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
  2020-06-11 20:09       ` J. Bruce Fields
  2020-06-11 22:46         ` Rick Macklem
  2020-06-11 23:00         ` Rick Macklem
@ 2020-06-12 13:26         ` Olga Kornievskaia
  2020-06-23 14:35           ` [PATCH] " J. Bruce Fields
  2 siblings, 1 reply; 14+ messages in thread
From: Olga Kornievskaia @ 2020-06-12 13:26 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: Schumaker, Anna, trondmy, linux-nfs, Steve Dickson

On Thu, Jun 11, 2020 at 4:09 PM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Fri, Jan 17, 2020 at 09:16:54PM +0000, Schumaker, Anna wrote:
> > On Fri, 2020-01-17 at 21:14 +0000, Trond Myklebust wrote:
> > > On Fri, 2020-01-17 at 21:09 +0000, Schumaker, Anna wrote:
> > > > Hi Olga,
> > > >
> > > > On Thu, 2020-01-16 at 14:08 -0500, Olga Kornievskaia wrote:
> > > > > From: Olga Kornievskaia <kolga@netapp.com>
> > > >
> > > > Have you done any testing with nconnect and the v4.0 replay caches? I
> > > > did some
> > > > digging on the mailing list and found this in one of the cover
> > > > letters from
> > > > Trond: "The feature is only enabled for NFSv4.1 and NFSv4.2 for now;
> > > > I don't
> > > > feel comfortable subjecting NFSv3/v4 replay caches to this treatment
> > > > yet."
> > > >
> > >
> > > That comment should be considered obsolete. The current code works hard
> > > to ensure that we replay using the same connection (or at least the
> > > same source/dest IP+ports) so that NFSv3/v4.0 DRCs work as expected.
> > > For that reason we've had NFSv3 support since the feature was merged.
> > > The NFSv4.0 support was just forgotten.
> >
> > Thanks for the explanation! I'll add the patch.
>
> What happened to this patch?  As far as I can tell, the conclusion of
> this thread was that it should be applied.

I decided not to submit this patch but anybody else is free to add
that patch to add support for 4.0 nconnect as there is no reason it
shouldn't be supported.

>
> --b.
>
> >
> > Anna
> >
> > >
> > > > Thanks,
> > > > Anna
> > > >
> > > > > Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> > > > > ---
> > > > >  fs/nfs/nfs4client.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
> > > > > index 460d625..4df3fb0 100644
> > > > > --- a/fs/nfs/nfs4client.c
> > > > > +++ b/fs/nfs/nfs4client.c
> > > > > @@ -881,7 +881,7 @@ static int nfs4_set_client(struct nfs_server
> > > > > *server,
> > > > >
> > > > >         if (minorversion == 0)
> > > > >                 __set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
> > > > > -       else if (proto == XPRT_TRANSPORT_TCP)
> > > > > +       if (proto == XPRT_TRANSPORT_TCP)
> > > > >                 cl_init.nconnect = nconnect;
> > > > >
> > > > >         if (server->flags & NFS_MOUNT_NORESVPORT)
> > > --
> > > Trond Myklebust
> > > Linux NFS client maintainer, Hammerspace
> > > trond.myklebust@hammerspace.com
> > >
> > >

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH] NFSv4.0 allow nconnect for v4.0
  2020-06-12 13:26         ` Olga Kornievskaia
@ 2020-06-23 14:35           ` J. Bruce Fields
  0 siblings, 0 replies; 14+ messages in thread
From: J. Bruce Fields @ 2020-06-23 14:35 UTC (permalink / raw)
  To: Olga Kornievskaia; +Cc: Schumaker, Anna, trondmy, linux-nfs, Steve Dickson

From: Olga Kornievskaia <kolga@netapp.com>

It looks like this "else" is just a typo.  It turns off nconnect for
NFSv4.0 even though it works for every other version.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 fs/nfs/nfs4client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Fri, Jun 12, 2020 at 09:26:47AM -0400, Olga Kornievskaia wrote:
> I decided not to submit this patch but anybody else is free to add
> that patch to add support for 4.0 nconnect as there is no reason it
> shouldn't be supported.

OK, resending, assuming Trond or Anna haven't already got this.--b.

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 0bd77cc1f639..5726f82bc468 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -880,7 +880,7 @@ static int nfs4_set_client(struct nfs_server *server,
 
 	if (minorversion == 0)
 		__set_bit(NFS_CS_REUSEPORT, &cl_init.init_flags);
-	else if (proto == XPRT_TRANSPORT_TCP)
+	if (proto == XPRT_TRANSPORT_TCP)
 		cl_init.nconnect = nconnect;
 
 	if (server->flags & NFS_MOUNT_NORESVPORT)
-- 
2.26.2



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, back to index

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 19:08 [PATCH 1/1] NFSv4.0 allow nconnect for v4.0 Olga Kornievskaia
2020-01-17 21:09 ` Schumaker, Anna
2020-01-17 21:14   ` Trond Myklebust
2020-01-17 21:16     ` Schumaker, Anna
2020-06-11 20:09       ` J. Bruce Fields
2020-06-11 22:46         ` Rick Macklem
2020-06-11 23:00         ` Rick Macklem
2020-06-12 13:26         ` Olga Kornievskaia
2020-06-23 14:35           ` [PATCH] " J. Bruce Fields
2020-01-20 15:35 ` [PATCH 1/1] " Steve Dickson
2020-01-23  0:23   ` Trond Myklebust
2020-01-27 18:39     ` Steve Dickson
2020-01-27 19:35       ` Trond Myklebust
2020-01-31 19:56 ` Olga Kornievskaia

Linux-NFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \
		linux-nfs@vger.kernel.org
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git