Re: 4.1 client reconnect bug

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

 



On Mon, Oct 17, 2011 at 02:57:52PM -0700, Trond Myklebust wrote:
> 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)...

OK, I think that makes sense.

--b.
--
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