J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Fri, Apr 22, 2022 at 11:03:17PM +0000, Rick Macklem wrote: > > J. Bruce Fields <bfields@xxxxxxxxxxxx> 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.
