On Wed, 2014-03-19 at 13:10 -0400, Steve Dickson wrote:
>
> On 03/19/2014 11:04 AM, Trond Myklebust wrote:
> > IOW: there is no way to make mount.nfs honour the ‘retry’ and/or ‘bg'
> > mount options in any consistent fashion by solely relying on kernel timeouts.
> I went back and took a look at how bg mounts worked in a number of
> older kernels f19(3.12) all the way back to RHEL6 kernel (2.6).
>
> I turns out you are right. The bg mounts were not depending on
> timeouts they were depended on the mount to fail with ECONNREFUSED
> The very first one, which is the reason the bg mount happen
> so fast...
>
> Its seems these days ECONNREFUSED are no longer return
> as an error codes. They basically are turned into a
> timeout... Just curious as to why ECONNREFUSED are
> no longer returned?
>
> Again, thanks for the cycles!
If the server is down during the initial rpc client creation, then I’d
still expect that to fail with ECONNREFUSED due to the rpc_ping() call.
Does the following patch help?
8<------------------------------------------------------------
>From dad628cc357a06cff8ce04300ba5c19bd92e73eb Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
Date: Wed, 19 Mar 2014 13:25:43 -0400
Subject: [PATCH] SUNRPC: Ensure call_status() deals correctly with SOFTCONN
tasks
Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
---
net/sunrpc/clnt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index cea1308a6fda..ef96568902c5 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2004,6 +2004,10 @@ call_status(struct rpc_task *task)
case -EHOSTDOWN:
case -EHOSTUNREACH:
case -ENETUNREACH:
+ if (RPC_IS_SOFTCONN(task)) {
+ rpc_exit(task, status);
+ break;
+ }
/*
* Delay any retries for 3 seconds, then handle as if it
* were a timeout.
--
1.8.5.3
--
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
