Subject: [nfsv4] How clients should deal with server reboot in v4.1

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 28 Oct 2007 10:18:30 -0400

As a result of looking at the locking sections of the spec as part of
addressing the review comments, and thinking about the error list
review, I've come to the conclusion that we can (and should) simplify
the logic for the client to take note of server reboot events.

I think we can take advantage of sessions so that the client will only
note server reboot events after doing session recovery and getting a
STALE_CLIENTID error.  STALE_STATEID errors will go away away as will
STALE_CLIENTID errors that occur for an existing session.  This would
also to apply to persistent sessions and reclaim would not occur due to
SEQ4_STATUS_RESTART_RECLAIM_NEEDED.  Reclaim in the peristent session
case would happen just as it does in the non-persistent case, after a
new session with a new clietid is established.

The reason we can do this derives from the fact that stateid's are
always tied to client IDs.  Every stateid is interpreted in the context
of a session and so we don't have the issue of recognizing stale
stateids as we do in v4.0.  We have the stale clientid/sessionid that
serves the purpose and once we know that is invalid, we have enough
information to indicate to the client that he has lost locking context.
We don't need a separate STALE_STATEID error.  If there has been a
server reboot, then the session is gone and thus no separate
STALE_CLIENTID error (see below for the persistent session case).

The biggest conceptual change involves persistent sessions.  The spec is
currently inconsistent about recovery in this situation.  In some places
we stress that after reboot, such a session is dead.  You can use it to
retry operations that were in flight after a disconnection, to mine the
persistent replay cache and find operations that were done before the
server reboot, but not to start new ones.  In other places it assumes
that you will continue 

To summarize, I propose:

     STALE_STATEID vanishes.  From the minor version point of view it 
     remains a defined error but no v4.1 op can return it.  In any 
     situation in which the server will be presented with stale 
     stateid/clientid co-ordinates, a  BAD_SESSION or DEAD_SESSION 
     error will result.

     STALE_CLIENTID is limited to ops where we explicitly send a 
     clientid, rather than using one derived from a session 
     (CREATE_SESSION and DESTROY_CLIENTID). Thus, any situation 
     in which a client will  attempt to manipulate locking state 
     and find out about a reboot, will first manifest as a BADSESSION
     or DEADSESSION and only when attempting to recover from that 
     would there be a STALE_CLIENTID.

     DEADSESSION would be returnable on all forward ops that can be 
     part of a session (all except EXCHANGE_ID) plus CB_SEQUENCE.  
     It needs to be added to the forward ops because you can have 
     a server reboot in which some COMPOUNDs are partially executed 
     and reissuing them on the persistent session will result in 
     a situation in which you recover status from the SEQUENCE and 
     some other ops in the COMPOUND but then reach some not executed 
     before the server failure.

     The status bit SEQ4_STATUS_RESTART_RECLAIM_NEEDED goes away 
     since you find out about server reboot for persistent sessions 
     in essentially the same way as you do for non-persistent 
     sessions.  In light of this,  all the stuff about needing to 
     do a TEST_STATEID when going a open-ecaim that might involve 
     an upgrade, also can go away.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4