Major issues with nfsv4

J David j.david.lists at
Sat Jan 16 05:23:51 UTC 2021

On Thu, Jan 14, 2021 at 5:30 PM Rick Macklem <rmacklem at> 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

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.)
(OpenOwner is now 3 and Opens is now 21.)
(OpenOwner is now 4 and Opens is now 24.)
(OpenOwner is now 5 and Opens is now 27.)
(OpenOwner is now 6 and Opens is now 30.)
(OpenOwner is now 7 and Opens is now 33.)
while true; do ls | true; done
(Allow about a minute to pass, hit CTRL-C.  OpenOwner is now 4647 and
Opens is now 13957)
(OpenOwner is now 4647 and Opens is now 13952.)

Back in Window 2:

(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

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?


More information about the freebsd-fs mailing list