https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249871
--- Comment #1 from Rick Macklem <rmack...@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=1
vfs.nfsd.enable_stringtouid=1
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-...@vger.kernels.org.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
