Source: linux
Version: 4.9.88-1
Severity: wishlist
Tags: patch
I've run into this capacity limitation in stretch, which is addressed
upstream in Linux 4.15 by the following commit:
commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6
Author: J. Bruce Fields <bfie...@redhat.com>
Date: Tue Sep 19 20:51:31 2017 -0400
nfsd: increase DRC cache limit
which trivially applies to Linux 4.9 (I haven't checked 3.16) and provides
significant relief in my use case. It would save me (and perhaps others)
work if this change could be included in Debian's 4.9 kernel packages;
otherwise I'll have to keep maintaining my own fork. (4.15 has other
issues so I don't want to use it in production yet.)
For the benefit of others who may be running into the same problem, here
is a more detailed description.
Symptom: an NFS server accepts only a limited number of concurrent v4.1+
mounts. Once that limit is reached, new clients get NFS4ERR_DELAY (10008)
replies to CREATE_SESSION. (This can be seen in the server's dmesg after
rpcdebug -m nfsd -s proc.) Increasing the number of nfsd threads has no
impact on the number of mounts allowed. A server with 512MB of RAM
only accepts 7 or 8 concurrent NFSv4.1+ mounts. From the perspective of
an affected client, mount.nfs appears to hang (triggering a kernel backtrace
after 120 seconds); in reality, though, it just keeps reissuing CREATE_SESSION
calls until one of them succeeds.
Pre-v4.1 clients are unaffected by this since sessions are new to NFS v4.1.
The proposed patch just increases the limit by an order of magnitude, at
the cost of using more kernel memory. As noted in comments in the source
code, it would be nice to make this tuneable by the server administrator.
