Received-SPF: softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <CAPt2mGNF=iZkXGa93yjKQG5EsvUucun1TMhN5zM-6Gp07Bni2g@mail.gmail.com>
 <20220107171755.GD26961@fieldses.org> <CAPt2mGPtxNzigMEYXKFX0ayVc__gyJcQJVHU51CKqU+ujqh7Cg@mail.gmail.com>
 <20220110145210.GA18213@fieldses.org> <20220110172106.GC18213@fieldses.org>
 <CAPt2mGPUa_VHHshXwLLCH=wvdrd6Hyb4gttMeEqKdgFV4GJY7g@mail.gmail.com>
 <20220123224238.GA9255@fieldses.org> <CAPt2mGMXHqBtWJhuEM76MY5tm0V=uAghKT21KRsHBQAfgkuJpg@mail.gmail.com>
In-Reply-To: <CAPt2mGMXHqBtWJhuEM76MY5tm0V=uAghKT21KRsHBQAfgkuJpg@mail.gmail.com>
From:   Daire Byrne <daire@dneg.com>
Date:   Mon, 7 Feb 2022 15:21:41 +0000
Message-ID: <CAPt2mGN-fqG3nMnrtaa8jWQpkTZYqQuWAR+EseD0d7CCfEPmzw@mail.gmail.com>
Subject: Re: nconnect & repeating BIND_CONN_TO_SESSION?
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Trond kindly posted a patch to fix the noresvport mount issue with
v4.2 and recent kernels.

I tested it quickly and verified ports greater than 1024 were being
used as expected, but it seems the same issue persists. It still feels
like it's related to the total number of server + nconnect pairings.

So I can have 20 servers mounted with nconnect=4 or 10 servers mounted
with nconnect=8 but any combination that increases the total
connection on the client past that and at least one of the servers
ends up in a state such that it's just sending a bind_conn_to_session
with every operation.

I'll see if I can discern anything from any packet capture (as
suggested earlier by Rick), but it's hard to reproduce exactly in time
and on demand. My theory is that maybe there is a timeout on the
callback and that adding more connections is just adding more
load/throughput and making a timeout more likely.

My workaround atm is to simply use NFSv3 instead of NFSv4 which might
be a better choice for this kind of workload anyway.

Daire


On Mon, 24 Jan 2022 at 12:33, Daire Byrne <daire@dneg.com> wrote:
>
> On Sun, 23 Jan 2022 at 22:42, J. Bruce Fields <bfields@fieldses.org> wrote:
> > > I suspect it's just more recent kernels that has lost the ability to
> > > use v4+noresvport
> >
> > Yes, thanks for checking that.  Let us know if you narrow down the
> > kernel any more.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=215526
>
> I think it stopped working somewhere between v5.11 and v5.12. I'll try
> and bisect it this week.
>
> Daire