Date: Sat, 16 Jan 2021 00:23:37 -0500 From: J David <j.david.lists@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Major issues with nfsv4 Message-ID: <CABXB=RQG_hR%2BVzC2mSiwK-9h8sEAQA5xrx2tjiKsPngoOMqxFQ@mail.gmail.com> In-Reply-To: <YQXPR0101MB0968C6331C1C1F33E18523C2DDA80@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR0101MB096849ADF24051F7479E565CDDCA0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CABXB=RSyN%2Bo2yXcpmYw8sCSUUDhN-w28Vu9v_cCWa-2=pLZmHg@mail.gmail.com> <YQXPR0101MB09680D155B6D685442B5E25EDDCA0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CABXB=RSSE=yOwgOXsnbEYPqiWk5K5NfzLY=D%2BN9mXdVn%2B--qLQ@mail.gmail.com> <YQXPR0101MB0968B17010B3B36C8C41FDE1DDC90@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <X9Q9GAhNHbXGbKy7@kib.kiev.ua> <YQXPR0101MB0968C7629D57CA21319E50C2DDC90@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <X9UDArKjUqJVS035@kib.kiev.ua> <CABXB=RRNnW9nNhFCJS1evNUTEX9LNnzyf2gOmZHHGkzAoQxbPw@mail.gmail.com> <YQXPR0101MB0968B120A417AF69CEBB6A12DDC80@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <X9aGwshgh7Cwiv8p@kib.kiev.ua> <CABXB=RTFSAEZvp%2BmoiF%2BrE9vpEjJVacLYa6G=yP641f9oHJ1zw@mail.gmail.com> <YQXPR0101MB09681D2CB8FBD5DDE907D5A5DDC40@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CABXB=RTLogtoFi%2BtAyUHii%2BWFCQtj1qFjbiz2CQC8whNYEBy2Q@mail.gmail.com> <YQXPR0101MB0968C6331C1C1F33E18523C2DDA80@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 14, 2021 at 5:30 PM Rick Macklem <rmacklem@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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RQG_hR%2BVzC2mSiwK-9h8sEAQA5xrx2tjiKsPngoOMqxFQ>