Date: Sat, 26 Sep 2020 15:48:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 249871] NFSv4 faulty directory listings under heavy load Message-ID: <bug-249871-227-MHKt1AFQV9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-249871-227@https.bugs.freebsd.org/bugzilla/> References: <bug-249871-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249871 --- Comment #1 from Rick Macklem <rmacklem@FreeBSD.org> --- Yep, that is weird. Assuming the clients are FreeBSD and not Linux, the only thing I can think of to try is take the "intr" option off the mounts. The BUGS section of "man mount_nfs" notes it should never be used. If somehow a signal were to be posted to the process on the client, that might explain this, if a sleep() returns ERESTART or something like that. --> Anyhow, for reasons mostly related to sessions (or lock sequencing for NFSv4.0) you should never use "intr" nor "soft" on NFSv4 mounts. I'll look through the code, but the NFSv3 and NFSv4 code is very similar for Readdir. One more question: - Are you using nfsuserd or uids in strings? If the former, you could try setting vfs.nfs.enable_uidtostring=3D1 vfs.nfsd.enable_stringtouid=3D1 and then don't run nfsuserd. (When the uid<->name cache misses, the upcall to the nfsuserd could take a long time on the heavily loaded server. However, I cannot think why slow response could cause this unless it is related to using "intr" on the mounts. If the clients are Linux, then I vaguely recall mention of problems with reading large directories being discussed on linux-nfs@vger.kernels.org. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-249871-227-MHKt1AFQV9>