On Sat, 2024-01-13 at 15:47 +0100, Roland Mainz wrote: > Hi! > > ---- > > Jess/Chuck: Who is in charge of the SPAM filter at kernel.org ? I'm > having problems sending ANY messages to the mailinglist, and it is > starting to frustrate me... ;-( > > ---- > > Bye, > Roland > > Forwarded Conversation > Subject: Turn NFSD_MAX_* into tuneables ? / was: Re: Increasing > NFSD_MAX_OPS_PER_COMPOUND to 96 > ------------------------ > > From: Roland Mainz <roland.mainz@xxxxxxxxxxx> > Date: Sat, Jan 13, 2024 at 3:22 PM > To: Linux NFS Mailing List <linux-nfs@xxxxxxxxxxxxxxx> > > > On Sat, Jan 13, 2024 at 1:19 AM Dan Shelton <dan.f.shelton@xxxxxxxxx> 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. > > More general question: > Is it feasible to turn the values for NFSD_MAX_* (max_ops, > max_req etc., e.g. everything which is being negotiated in a NFSv4.1 > session) into tuneables, which are set at nfsd startup ? It might help > with Dan's scenario, benchmarking, client testing (e.g. my case, where > I switched to nfs4j) and tuning... > (re-cc'ing the mailing list...) We generally don't like to add knobs like this when we can get by with just tuning a sane value for everyone. This particular value governs the maximum number of operations per compound. I don't see any value in keeping it artificially low. The only real argument against it that I can see is that it might make it easier for a malicious or badly-designed client to DoS the server. That's certainly something we should be wary of, but I don't expect that increasing the max from 50 to ~100 will make a big difference there. -- Jeff Layton <jlayton@xxxxxxxxxx>
