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