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

[Dai Ngo <dai.ngo@oracle.com>]

On 11/3/25 12:15 PM, Chuck Lever wrote:
> On 11/3/25 2:14 PM, Dai Ngo wrote:
>>>    and I disagree that fencing is harsh, because
>>> NFS4ERR_RETRY_UNCACHED_REP is supposed to be quite rare, and of course
>>> there are other ways this error can happen.
>> Yes, this error should be rare. But is fencing the client is a correct
>> solution for it? IMHO, NFS4ERR_RETRY_UNCACHED_REP means the client has
>> received and replied to the server, it just somehow the server did not
>> see the reply due to many reasons.
> Fencing seems appropriate when there is a clear indication that the
> client and server state are out of sync. The question is why, and how do
> we prevent that situation from occurring? And, when we get into this
> state, what is the correct recovery?
>
> I don't see NFSD doing this short-circuit when processing a CB_RECALL
> response, for instance.
>
>
>> I think in this case we should just
>> mark the back channel down and let the client recover it, instead of
>> fencing the client.
> Clearly the backchannel needs to recover properly from
> NFS4ERR_RETRY_UNCACHED_REP, and if it goes into a loop, something is not
> right. I don't think this is the correct fix for looping, either.
>
> I don't understand why, after the server indicates a backchannel fault,
> the client and server don't replace the session. The server is trying
> to re-use what is obviously an incorrect slot sequence ID; it shouldn't
> expect any different result by retrying.
>
> So, yes, there are one or more real bugs here. But ignoring a sign that
> state synchrony has been lost is not the right fix.

ok, I'll drop this patch. This error occurs due to the hard hang problem.
In that case, there is no back channel recovery, no new session, etc takes
place, the callback code just keep retrying forever.

Let fix the hang problem first and we can take care of this error later
if it still happens.

-Dai