Re: [PATCH] SUNRPC: increase max timeout for rebind to handle NFS server restart

[dai.ngo@oracle.com]

On 4/18/23 9:02 AM, Trond Myklebust wrote:
> On Mon, 2023-04-17 at 18:04 -0700, dai.ngo@oracle.com wrote:
>> On 4/17/23 5:23 PM, Trond Myklebust wrote:
>>> task->tk_rebind_retry is _only_ changed if the rpcbind server is up
>>> and
>>> running, and returns an empty reply because the service we're
>>> looking
>>> up isn't registered.
>>> task->tk_rebind_retry isn't changed on any request timeout. It
>>> isn't
>>> changed on any connection failure. It isn't changed by any other
>>> code
>>> path in the RPC client.
>>>
>>> So none of this applies to the case of a dead server.
>> Sorry if I'm not clear. What I meant by a dead server is a dead NFS
>> server and not rpcbind service. So in this case we get EACCES from
>> rpcbind and we retry.
>>
>>> It applies to the case of a live server, where rpcbind is running
>>> and
>>> accessible to the client and where, for some reason or another, it
>>> is
>>> taking an exceptionally long time to register the service we are
>>> looking up the port for (either NLM or NFSv3).
>> Yes, this is the problem that I'm facing.
>>
>>> So where are you seeing this process take 90 seconds? Why do we
>>> need to
>>> wait for that long before we can finally conclude that the
>>> particular
>>> service in question is not going to come back up?
>> 90 secs wait is for when the NFS server never come up and we keep
>> getting
>> EACCES from rpcbind for this whole time.
>>
> OK, so the 90s is completely arbitrary then, and was only chosen
> because it fits your particular server?
>
> To me, that appears to invalidate the entire premise of commit
> 0b760113a3a1 that we can rely on rpcbind to tell us if the service is
> present or not.
> In that case, I'd rather rip out the task->tk_rebind_retry counter, and
> just rely on standard hard/soft task semantics.

Okay, I will resend the patch that relies on standard hard/soft task semantics.

Thanks,
-Dai