Received-SPF: pass (google.com: domain of linux-nfs+bounces-1072-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <CAAvCNcDtTNDRvUVjUy4BE7eBCgmkb6hfkq3P0jaGDC=OXg0=6g@mail.gmail.com>
 <89fba598b0b93cf97bf208e106001f74eadd1829.camel@kernel.org>
In-Reply-To: <89fba598b0b93cf97bf208e106001f74eadd1829.camel@kernel.org>
From: Roland Mainz <roland.mainz@nrubsig.org>
Date: Sat, 13 Jan 2024 08:20:00 +0100
Message-ID: <CAKAoaQmQzvCxhB_8Lg2JzMvAVA7ZQrsAZeQegHaJDt1NaofR0A@mail.gmail.com>
Subject: Re: Increasing NFSD_MAX_OPS_PER_COMPOUND to 96
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>, ms-nfs41-client-devel@lists.sourceforge.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 13, 2024 at 2:32=E2=80=AFAM Jeff Layton <jlayton@kernel.org> wr=
ote:
> On Sat, 2024-01-13 at 01:19 +0100, Dan Shelton wrote:
> > We've been experiencing significant nfsd performance problems with a
> > customer who has a deeply nested filesystem hierarchy, lots of
> > subdirs, some of them 60-80 dirs deep (!!), which leads to an
> > exponentially slowdown with nfsd accesses.
> >
> > Some of the issues have been addressed by implementing a better
> > directory walker via multiple dir fds and openat() (instead of just
> > cwd+open()), but the nfsd side still was a pretty dramatic issue,
> > until we bumped #define NFSD_MAX_OPS_PER_COMPOUND in
> > linux-6.7/fs/nfsd/nfsd.h from 50 to 96. After that the nfsd side
> > behaved MUCH more performant.
>
> I guess your clients are trying to do a long pathwalk in a single
> COMPOUND?

Is there a problem with that (assuming NFSv4.1 session limits are honored) =
?

> Is this the windows client?

No, the ms-nfs41-client (see
https://github.com/kofemann/ms-nfs41-client) uses a limit of |16|, but
it is on our ToDo list to bump that to |128| (but honoring the limit
set by the NFSv4.1 server during session negotiation) since it now
supports very long paths ([1]) and this issue is a known performance
bottleneck.

[1]=3DWindows 10 build 1607 allows longer paths than the infamous
|MAXPATH|, see https://learn.microsoft.com/en-us/windows/win32/fileio/maxim=
um-file-path-limitation?tabs=3Dregistry

> At first glance, I don't see any real downside to increasing that value.
> Maybe we can bump it to 100 or so? What would probably be best is to
> propose a patch so we can discuss the change formally.

AFAIK the Solaris 11's and Illumos's (see
https://github.com/racktopsystems/illumos-gate/commit/27e4199512d9d7b1e5409=
904f13cd96d8a05ee6e)
limit is AFAIK |NFS4_COMPOUND_LIMIT| (=3D|2048|), both capped by the
limits negotiated at NFSv4.1 session creation, if I recall it
correctly...

----

Bye,
Roland
--=20
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /=3D=3D\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)