Re: [PATCH 2/3] NFSD: Do not fence the client on NFS4ERR_RETRY_UNCACHED_REP error

[Chuck Lever <chuck.lever@oracle.com>]

On 11/3/25 6:45 AM, Christoph Hellwig wrote:
> On Sat, Nov 01, 2025 at 11:51:34AM -0700, Dai Ngo wrote:
>> NFS4ERR_RETRY_UNCACHED_REP error means client has seen and replied
>> to the layout recall, no fencing is needed.
> 
> RFC 5661 specifies that error as:
> 
>   The requester has attempted a retry of a Compound that it previously
>   requested not be placed in the reply cache.
> 
> which to me doesn't imply a positive action here.

Agreed, this status code seems like a loss of synchronization of session
state between the client and server, or an implementation bug. Ie, it
seems to mean that at the very least, session re-negotiation is needed,
at first blush. Should the server mark a callback channel FAULT, for
instance?


> But I'm not an
> expert at reply cache semantics, so I'll leave others to correct me.
> But please add a more detailed comment and commit log as this is
> completely unintuitive.

The session state and the state of the layout are at two different
and separate layers. Connect the dots to show that not fencing is
the correct action and will result in recovery of full backchannel
operation while maintaining the integrity of the file's content.

So IMHO reviewers need this patch description to provide:

- How this came up during your testing (and maybe a small reproducer)

- An explanation of why leaving the client unfenced is appropriate

- A discussion of what will happen when the server subsequently sends
  another operation on this session slot


-- 
Chuck Lever