Re: Problems with NFS4.1 on ESXi

[Rick Macklem <rmacklem@uoguelph.ca>]

J. Bruce Fields <bfields@fieldses.org> wrote:
> On Fri, Apr 22, 2022 at 11:03:17PM +0000, Rick Macklem wrote:
> > J. Bruce Fields <bfields@fieldses.org> wrote:
> > > Actually (sorry I'm slow to understand this)--why would our 4.1 server
> > > ever be returning STALE on a close?  We normally hold a reference to the
> > > file.
> > Well, OPEN_RESULT_PRESERVE_UNLINKED is not set in the Open reply,
> > so even if it normally does so, it is not telling the ESXi client that it
> > will retain it.
>
> Yeah, we don't guarantee it, but I thought in this cases we did.  The
> object we use to represent the open stateid (indirectly) holds a
> reference on the inode that prevents it from being removed, so the
> filehandle lookup should still work.  If I had the time, I'd write an
> open-rename over-close test in pynfs and see if we could reproduce this,
> and if so see what's happening.
Then I guess the next question would be...
What happens to the file/open when the close never happens?

Could that be causing problems for the client, since we know the Close
never happens?

> > > Oh, wait, is subtree_check set on the export?  You don't want to do
> > > that.  (The freebsd server probably doesn't even give that as an
> > > option?)
> > Nope, Never heard of it.
> 
> It adds a reference to the parent into the filehandle, so we can foil
> filehandle-guessing attacks on exports of subdirectories of filesystems.
> With the major drawback that it breaks on cross-directory rename, for
> example.  So it's not the default.
In FreeBSD, it actually hangs onto the parent's FH (verbatim), but mostly
so it can do Open/Claim_NULLs for it. There is nothing in FreeBSD that
tries to subvert FH guessing.

rick

--b.