Subject: [nfsv4] Persistent sessions, NFS4ERR_STALE_CLIENTID and related stuff

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 12 Oct 2007 17:03:20 -0400

This email is about some issues that arose in reviewing the v4.1 mapping
of ops to the set of acceptable errors, but since it turns out that
possible solutions change the protocol in ways that are outside the
scope of the error sets (not enormous though), I'm sending this to the
working group as a whole.

The issue started with the question of whether it was valid for
operations within a session context, beyond SEQUENCE, to return the
error NFS4ERR_STALE_CLIENTID.  From what I've been able to determine,
this is the general opinion among people doing the error review, but I
had been worried that this was not right.  To anticipate my conclusion a
bit, I think there are a number of reasonable options here, one of which
is to allow OPEN to return NFS4ERR_STALE_CLIENTID.

So as the protocol stands in draft-14, when we have a server reboot and
the session is persistent, we have session in a somewhat odd state.
Although, the spec does not use this word, the session is in a kind of
moribund state.  You can do operations on it, but you can't do
state-related operations.  Any that involve operations that incorporate
state in the args will return NFS4ERR_STALE_STATEID.

This state of affairs is a consequence of the fact that on a reboot with
a persistent session, the server retains information about the session
but not about locking.  (If the server managed to also retain
information about lock state persistently, we would have a situation
that looked, from the protocol point of view, not like a reboot, but
merely as a temporary communication failure).  Although the spec says
that the clientid like the session is persistent, this only means that
the clientid is recognized and you don't get NFS4ERR_STALE_CLIENTID on
SEQUENCE; you can't access the state from the previous session instance.

So this causes issues for requests like OPEN that manipulate state but
which don't have stateid's in their arguments of which OPEN is the big
issue.  In draft-14, there is a very large case-by-case discussion of
this in section 18.46.5 including restrictions on open-upgrades during
reclaim.  I believe that this complexity is unneeded, if we simply do
the same thing with a stale clientid as we do with stale stateids, and
that is reject the OPEN if the clientid is one associated with a
moribund session, i.e. one that has a clientid which cannot be used to
manipulate state.

This approach would differ from the current spec which stresses that
with a persistent session, the sessionid and clientid are still "valid"
after the reboot.  Where I think this goes astray is that the clientid
may be valid for the purpose of accepting a SEQUENCE, but not valid for
the purpose of using it to change the state corpus associated with that
clientid.  So I'm proposing that such clientids be considered moribund
just as the session is.  They really continue to exist mainly for the
purpose of making sure we know what operations from the previous
instance of the session were completed and how (the
exactly-one-semantics function).  So if the clientid is a moribund one,
then SEQUENCE would not return NFS4ERR_STALE_CLIENTID, although OPEN
would.  Alternatively, we could create a new error for OPEN ot return in
this situation if we find it too disconcerting that the same clientid
would generate NFS4ERR_STALE_CLIENTID for one op but not another.

Another alternative would be to draw the line between allowed and
not-allowed operations on moribund sessions in a different place.  The
idea would be that for such sessions it would be valid only to re-issue
requests/ops already executed, and any new requests/ops on such a
session would be rejected with an error, let's say NFS4ERR_OLD_SESSION.
Since you could have partially executed requests, any op that could be
part of session could return that error.  This would allow you to delete
NFS4ERR_STALE_CLIENTID from OPEN and NFS4ERR_STALE_STATEID from all ops
in which it appeared.  This is because validity of the state corpus is
tied to clientids which are in turn are tied to sessions.  You simply
could not get past the session layer with a stateid/ckientid pair from
an earlier instance.  If you sent the bit pattern from the stateid form
an earlier clientid, you would get NFS4ERR_BAD_STATEID.

I think either of these are valid approaches and both are superior to
what we currently have in draft-14.  Both would allow us to delete the
current restriction on open-upgrade on reclaim and most of the big
case-by-case discussion in section 18.46.5.

Comments?

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 13 Oct 2007 08:50:53 -0400

I've been doing a little more research about this, and it appears that
draft-14, at least in part, does embrace the second of the alternatives
I offered.  Section 2.10.5.5 talks about what I have been calling
"moribund sessions" and calls them "dead". 

So that leaves two issues:

     The treatment there is incomplete because it does not recognize 
     that a COMPOUND may be partially executed at the time of server 
     reboot, so that you can have a request that considered a replay
     at SEQUENCE but has new ops (including possibly nasty ones changing
     state).

     The treatment related issues in section 9.8 and 18.46.5 ignore the
     fact that the session will be dead.  With the server handling dead
     sessions properly, many of he situations that it discusses should 
     not be possible.

Discussion on this will probably continue, but for my version of the
error xml for the eror review, I am going to:

     Add NFS4ERR_DEADSESSION to all ops that can be in a sesssion 
     context (not callbacks).

     Delete NFS4ERR_STALE_CLIENTID from everything except sequence.

     Delete NFS4ERR_STALE_STATEID from everything.

BTW, NFS4ERR_LEASE_MOVED is also going away, a least in my version of
the xml.

-----Original Message-----
From: Noveck, Dave 
Sent: Friday, October 12, 2007 5:03 PM
To: [email-masked]
Subject: [nfsv4] Persistent sessions,NFS4ERR_STALE_CLIENTID and related
stuff

Comments?