Re: 4.1 client reconnect bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2011-10-17 at 17:04 -0400, J. Bruce Fields wrote: 
> Following up on a pub conversation from a couple weeks ago:
> 
> The client apparently assumes that (in the absence of state protection)
> sending a SEQUENCE over a new tcp connection to the server automatically
> associates the new tcp connection with both the forechannel and
> backchannel of the session.
> 
> The server currently assumes that the new tcp connection should be
> associated only with the forechannel.
> 
> RFC 5661 sides with the forechannel-only convention:
> 
> 	- 2.6.10.6.2: "If the client wants to use additional connections
> 	  for the backchannel, then it needs to call
> 	  BIND_CONN_TO_SESSION on each connection it wants to use with
> 	  the session."
> 
> 	- 2.10.13.1.2: "If the connection that was lost was the last one
> 	  associated with the backchannel, and the client wants to
> 	  retain the backchannel and/or prevent revocation of recallable
> 	  state, the client needs to reconnect, and if it does, it MUST
> 	  associate the connection to the session and backchannel via
> 	  BIND_CONN_TO_SESSION."
> 
> 	- 18.34.3: "If, when the client ID was created, the client opted
> 	  for SP4_NONE state protection, the client is not required to
> 	  use BIND_CONN_TO_SESSION to associate the connection with the
> 	  session, unless the client wishes to associate the connection
> 	  with the backchannel."
> 
> That means that currently if the client attempts to reconnect (e.g. to
> resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION
> set on future SEQUENCE replies.

Agreed, however in this case the BIND_CONN_TO_SESSION can be treated as
an optimisation. We should fix it soon, but as long as the existing
clients handle the path down error correctly (which we do by starting a
recovery thread, then resetting the session), then we are able to
function.

IOW: This is something that was on our 'B' list of items to complete
(i.e. after basic session+pnfs functionality)...

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux