Date: Sat, 12 Dec 2020 19:50:58 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: J David <j.david.lists@gmail.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Major issues with nfsv4 Message-ID: <X9UDArKjUqJVS035@kib.kiev.ua> In-Reply-To: <YQXPR0101MB0968C7629D57CA21319E50C2DDC90@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <CABXB=RRB2nUk0pPDisBQPdicUA3ooHpg8QvBwjG_nFU4cHvCYw@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 12, 2020 at 05:33:06PM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > >Nullfs vnodes keep a reference on the lower vnode. When nullfs vnode > >caching is enabled, nullfs vnodes survive after a vfs syscall is finished. > > > >NFSv4 mount automatically sets flag MNTK_NULL_NOCACHE that disables nullfs > >vnode cache. > Thanks Kostik, I see that. (And I recall discussions about disabling the nullfs caching.) > > Now, if I understand it correctly, if vrele() is called with the vnode shared locked, > then VOP_INACTIVE() won't be called. > --> It is VOP_INACTIVE()/VOP_RECLAIM() in the NFSv4 client that does the closes. > Normally the NFS client calls vput() when the vnode is locked, but is there a case > where nullfs might cause vrele() to be called on the lower vp when it is shared > locked? (Delaying closes until VOP_RECLAIM() would cause problems, I think?) If vput() is called with the vnode shared-locked, it tries to upgrade to exclusive with LK_NOWAIT. If sleep-less upgrade fails, invalidation is postponed. In practice, the failure to upgrade the lock is not too common, because caller drops the last use reference on the vnode, but it still happens. That said, I do not believe that this situation causes the problems OP described. I want to see what is going on in the exiting process. > > Note that, until we see the "nfsstat -c -E" we won't know if lots of opens > are an issue anyhow. > > Thanks for the help, rick >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X9UDArKjUqJVS035>