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. > > 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. --b.
