On Mar 18, 2014, at 11:47, Steve Dickson <SteveD@xxxxxxxxxx> wrote:
> Hey,
>
> On 03/17/2014 02:40 PM, Trond Myklebust wrote:
>> When the server is unavailable due to a networking error, etc, we want
>> the RPC client to respect the timeout delays when attempting to reconnect.
>>
>> Fixes: 561ec1603171 (SUNRPC: call_connect_status should recheck bind..)
>> Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
>> ---
>> net/sunrpc/clnt.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>> index 0edada973434..f22d3a115fda 100644
>> --- a/net/sunrpc/clnt.c
>> +++ b/net/sunrpc/clnt.c
>> @@ -1798,10 +1798,6 @@ call_connect_status(struct rpc_task *task)
>> trace_rpc_connect_status(task, status);
>> task->tk_status = 0;
>> switch (status) {
>> - /* if soft mounted, test if we've timed out */
>> - case -ETIMEDOUT:
>> - task->tk_action = call_timeout;
>> - return;
>> case -ECONNREFUSED:
>> case -ECONNRESET:
>> case -ECONNABORTED:
>> @@ -1812,7 +1808,9 @@ call_connect_status(struct rpc_task *task)
>> if (RPC_IS_SOFTCONN(task))
>> break;
>> case -EAGAIN:
>> - task->tk_action = call_bind;
>> + case -ETIMEDOUT:
>> + /* Check if we've timed out before looping back to call_bind */
>> + task->tk_action = call_timeout;
>> return;
>> case 0:
>> clnt->cl_stats->netreconn++;
>>
> How is this support to work if the trunking code still ignores timeouts?
>
> [ 2076.045176] NFS: nfs4_discover_server_trunking after status -110, retrying
The above patch fixes the regression that Neil tracked down in Linux 3.12, and that affects the generic RPC handling of soft timeouts.
The trunking code's handling of ETIMEDOUT has been there since Linux 3.7 and hasn’t changed, so I really don’t see how it can have worked at one time before 3.12.
_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
