On Apr 8, 2008, at 1:55 PM, Trond Myklebust wrote:
On Tue, 2008-04-08 at 13:38 -0400, Chuck Lever wrote:
Commits 66af1e55 through 663b8858 recently changed how
xs_tcp_state_change() awakens RPC tasks in order to address problems
with disconnection of TCP sockets that were already connected.
The generic function xprt_connect_status() is invoked during a
transport
connection operation by this wake-up. It expects a specific error
value
describing the connection failure, but currently always gets
ENOTCONN.
Does it? AFAICS, the only errors that it cares about are ETIMEDOUT,
ENOTCONN, ECONNRESET, and ECONNREFUSED, and the only effect is change
the dprintk() message.
OTOH, call_connect_status() will cause the task to exit with an EIO if
ever it gets sent an ECONNRESET or ECONNREFUSED.
Well, OK... but why keep the extra switch arms in xprt_connect_status
if transports and the generic logic don't use those error codes? It
serves only to confuse.
Last week, you claimed:
> The client currently doesn't retry in the case of a connection
> failing for a soft RPC request.
In fact, it does retry a connection attempt on soft RPC requests
until a *major* timeout occurs.
So is the actual bug in call_timeout?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
