Major issues with nfsv4

[J David]

On Thu, Jan 14, 2021 at 5:30 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:
> One thing to try (other than a FreeBSD13/head system, if possible)
> is the "oneopenown" mount option.

The odds of being able to run an unreleased version of FreeBSD on
production servers are slim to none.

While trying to develop a reproduction, I think I have narrowed down
what the problem is.  There are no jails or nullfs involved here, just
NFSv4.1.

Window 1: (to track OpenOwner/Opens)

while true; do date; nfsstat -E -c | fgrep -A1 OpenOwner; sleep 1; done

Window 2:

mount -o ro,nfsv4,minorversion=1,nosuid fileserver:/path/to/freesbd/root /mnt
chroot /mnt

(OpenOwner is now 1 and Opens is now 9.)

Window 3:

chroot /mnt
(OpenOwner is now 2 and Opens is now 18.)
ls
(OpenOwner is now 3 and Opens is now 21.)
ls
(OpenOwner is now 4 and Opens is now 24.)
ls
(OpenOwner is now 5 and Opens is now 27.)
ls
(OpenOwner is now 6 and Opens is now 30.)
ls
(OpenOwner is now 7 and Opens is now 33.)
bash
while true; do ls | true; done
(Allow about a minute to pass, hit CTRL-C.  OpenOwner is now 4647 and
Opens is now 13957)
exit
exit
(OpenOwner is now 4647 and Opens is now 13952.)

Back in Window 2:

exit
(wait about 30 seconds, OpenOwner is now 0 and Opens is now 0.)

So it looks like the NFSv4 code can't let go of *any* Opens on a
file/directory until *all* references to that file/directory are
closed.

If chroot is too much, "vi /mnt/etc/motd" in Window 2 and "cat
/mnt/etc/motd" in Window 3 have the same effect, leaking one Open per
cat instead of 3.  You probably don't even need a FreeBSD install on
the NFS mount; just hold a single file open in one window and
open/close it repeatedly in another.

Then I re-tested this with "-o
ro,nfsv4,minorversion=1,nosuid,oneopenown."  At least for this simple
case, the problem did not occur with oneopenown set.

Are there downsides to the oneopenown flag other than breaking delegations?

Thanks!