IMO there should be a debug setting to turn this off, as it might cause bugs in production environments. Similar to -O0 for cc, just in case. Ced On Tue, 10 Jun 2025 at 14:03, Dai Ngo <dai.ngo@xxxxxxxxxx> wrote: > > > On 6/10/25 2:59 AM, Cedric Blancher wrote: > > On Tue, 10 Jun 2025 at 02:17, Dai Ngo > > <dai.ngo=40oracle.com@xxxxxxxxxxxxxx> wrote: > >> On 6/9/25 4:35 PM, Rick Macklem wrote: > >>> Hi, > >>> > >>> I hope you don't mind a cross-post, but I thought both groups > >>> might find this interesting... > >>> > >>> I have been creating a compound RPC that does REMOVE and > >>> then tries to determine if the file object has been removed and > >>> I was surprised to see quite different results from the Linux knfsd > >>> and Solaris 11.4 NFSv4.1/4.2 servers. I think both these servers > >>> provide FH4_PERSISTENT file handles, although I suppose I > >>> should check that? > >>> > >>> First, the test OPEN/CREATEs a regular file called "foo" (only one > >>> hard link) and acquires a write delegation for it. > >>> Then a compound does the following: > >>> ... > >>> REMOVE foo > >>> PUTFH fh for foo > >>> GETATTR > >>> > >>> For the Solaris 11.4 server, the server CB_RECALLs the > >>> delegation and then replies NFS4ERR_STALE for the PUTFH above. > >>> (The FreeBSD server currently does the same.) > >>> > >>> For a fairly recent Linux (6.12) knfsd, the above replies NFS_OK > >>> with nlinks == 0 in the GETATTR reply. > >>> > >>> Hmm. So I've looked in RFC8881 (I'm terrible at reading it so I > >>> probably missed something) and I cannot find anything that states > >>> either of the above behaviours is incorrect. > >>> (NFS4ERR_STALE is listed as an error code for PUTFH, but the > >>> description of PUTFH only says that it sets the CFH to the fh arg. > >>> It does not say anything w.r.t. the fh arg. needing to be for a file > >>> that still exists.) Neither of these servers sets > >>> OPEN4_RESULT_PRESERVE_UNLINKED in the OPEN reply. > >>> > >>> So, it looks like "file object no longer exists" is indicated either > >>> by a NFS4ERR_STALE reply to either PUTFH or GETATTR > >>> OR > >>> by a successful reply, but with nlinks == 0 for the GETATTR reply. > >>> > >>> To be honest, I kinda like the Linux knfsd version, but I am wondering > >>> if others think that both of these replies is correct? > >>> > >>> Also, is the CB_RECALL needed when the delegation is held by > >>> the same client as the one doing the REMOVE? > >> The Linux NFSD detects the delegation belongs to the same client that > >> causes the conflict (due to REMOVE) and skips the CB_RECALL. This is > >> an optimization based on the assumption that the client would handle > >> the conflict locally. > > Does Linux nfsd have a setting to turn such optimizations OFF (all of them)? > > There is no setting to turn off the optimization of delegation recall from > the same client. > > -Dai > > > > > Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
