Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 24 Apr 2022 11:07:25 -0400
From:   "J. Bruce Fields" <bfields@fieldses.org>
To:     Rick Macklem <rmacklem@uoguelph.ca>
Cc:     "crispyduck@outlook.at" <crispyduck@outlook.at>,
        Chuck Lever III <chuck.lever@oracle.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Problems with NFS4.1 on ESXi
Message-ID: <20220424150725.GA31051@fieldses.org>
References: <AM9P191MB1665484E1EFD2088D22C2E2F8EF59@AM9P191MB1665.EURP191.PROD.OUTLOOK.COM>
 <AM9P191MB16655E3D5F3611D1B40457F08EF49@AM9P191MB1665.EURP191.PROD.OUTLOOK.COM>
 <4D814D23-58D6-4EF0-A689-D6DD44CB2D56@oracle.com>
 <AM9P191MB16651F3A158CAED8F358602A8EF49@AM9P191MB1665.EURP191.PROD.OUTLOOK.COM>
 <20220421164049.GB18620@fieldses.org>
 <20220421185423.GD18620@fieldses.org>
 <YT2PR01MB973028EFA90F153C446798C1DDF49@YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM>
 <20220422151534.GA29913@fieldses.org>
 <YT2PR01MB9730B98D68585B3B1036F6EEDDF79@YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YT2PR01MB9730B98D68585B3B1036F6EEDDF79@YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

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.

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