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
> >
> >
next prev 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).