Received-SPF: pass (google.com: domain of linux-nfs+bounces-1068-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: Dan Shelton <dan.f.shelton@gmail.com>
Date: Sat, 13 Jan 2024 02:47:23 +0100
Message-ID: <CAAvCNcBSW7ZH4LpSLLo+Bmh2kQ=w5sFrLJ-PKDDSBKwkS5fd5g@mail.gmail.com>
Subject: Re: Increasing NFSD_MAX_OPS_PER_COMPOUND to 96
To: Jeff Layton <jlayton@kernel.org>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Sat, 13 Jan 2024 at 02:32, Jeff Layton <jlayton@kernel.org> wrote:
>
> On Sat, 2024-01-13 at 01:19 +0100, Dan Shelton wrote:
> > Hello!
> >
> > 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?

Likely.

> Is this the windows client?

No, clients are Solaris 11, Linux and freeBSD

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

OK. How does this work?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd