linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "J. Bruce Fields" <bfields@fieldses.org>,
	"Schumaker, Anna" <Anna.Schumaker@netapp.com>
Cc: "olga.kornievskaia@gmail.com" <olga.kornievskaia@gmail.com>,
	"trondmy@hammerspace.com" <trondmy@hammerspace.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"steved@redhat.com" <steved@redhat.com>
Subject: Re: [PATCH 1/1] NFSv4.0 allow nconnect for v4.0
Date: Thu, 11 Jun 2020 23:00:42 +0000	[thread overview]
Message-ID: <QB1PR01MB3364AD78CCC13240528BC96CDD800@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20200611200919.GF16376@fieldses.org>

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
> >
> >


  parent reply	other threads:[~2020-06-11 23:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=QB1PR01MB3364AD78CCC13240528BC96CDD800@QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM \
    --to=rmacklem@uoguelph.ca \
    --cc=Anna.Schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=olga.kornievskaia@gmail.com \
    --cc=steved@redhat.com \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).