Hi, Florian reports that the --maxthreads option for nfsd, which defaults to 8 * ncpus is not restricted by the MAXNFSDCNT constant. He is correct, however my personal option is that this is a feature and not a bug. Below you will find what I said as a comment on the PR.
I'd like to get a "collective opinion" on this, so please comment w.r.t. whether you think the MAXNFSDCNT limit of 256 should be enforced for --maxthreads. Here is what I said in the bugzilla PR (with a few typos fixed): I would consider this behaviour (ignoring MAXNFSDCNT) a feature and not a bug. MAXNFSDCNT is cruft left over from decades ago when nfsd kernel threads were processes. You'll notice some ancient cruft where children[MAXNFSCNT] is defined, but only children[0] is actually used. (That cruft should be cleared out, but it is harmless.) You'll also notice that MAXNFSDCNT is defined as 256 and I am pretty sure that there are servers that want to use more than that limit now (and have been able to do so for more than a decade, due to the commit you mention). To change that now would be a POLA violation, imho. Why don't you just use the --maxthreads option to set the limit to what you need? (If this doesn't work, that is a bug that needs to be fixed.) I'll admit that "man nfsd" is misleading, in that it states that "-n" is the equivalent of setting both --minthreads and --maxthreads to the same value. This is inaccurate, as you note. It should say that "-n" is deprecated in favor of --minthreads, --maxthreads. Note that having too many kernel threads does not impact the system much. An inactive kernel thread mostly just uses a few pages for its kernel stack. (Minimal compared to the "processes" used decades ago.) Thanks for your comments, rick
