Major issues with nfsv4
rmacklem at uoguelph.ca
Sun Jan 17 14:49:18 UTC 2021
J David wrote:
>On Sat, Jan 16, 2021 at 5:57 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:
>> Opens can be closed until all FreeBSD open file descriptors for the file
>> are closed.
>> --> Just the way it is. It is not an unintended leak. They go away once
>> all file descriptors get closed,
>> However, none of the above seems unexpected, except maybe for why
>> "ls" in the chroot opens 3 regular files each time. I don't know what
>> chroot actually does for something like "ls"? I'll look.
>It probably isn't anything ls is doing. It's probably just the open
>of whatever shared libraries ls has in common with the shell running
>in the other window.
>And so, on a long-running system with frequently-accessed binaries (or
>just shared libraries) mounted over NFS, where it's unlikely that all
>descriptors will ever be closed at the same time, a hang/crash/failure
>essentially becomes inevitable?
Yes. If you have NFSv4 mounted shared libraries and an environment
where there is at least one process running using a given shared library
on the mount at any time, the NFSv4 Opens will accumulate and
eventually constipate the mount.
>Is this a solvable problem? (Outside of oneopenown.)
For this case, "oneopenown" is your only option.
I think there might have been a nullfs/NFSv4 interaction issue,
but it appears to be resolved in FreeBSD13.
More information about the freebsd-fs