Subject: [nfsv4] more re: NFS4ERR_EXPIRED

From: [email-masked]
Date: Tue, 13 Apr 2004 12:43:38 -0400 (EDT)

> Excellent example and question.  Here's my take.
and a most excellent response. (I have clipped out various sections.)

> I would say that BAD_STATEID is returned because only a single stateid
> was released by the server and because returning EXPIRED would imply,
> first that a lease expired, which it hasn't, and second, that all of
> the stateid's associated with the lease were released, which also is
> not true.
> 
> If the stateid was discarded because the lease expired and all of the
> stateids associated with the lease were expired at the same time, then
> EXPIRED should be returned.

Sounds good to me. (Its what my server currently does.)

> On the other hand, if the lease expired and the delegation were discarded
> because of a conflicting lock (so that other stateids associated with the
> same lease might survive and be revived), then BAD_STATEID is to be returned,
> even if the occasion for discarding the stateid were the lease expiration
> (e.g. there has been a conflict with the delegation in existence and once
> the lease expired, that kicked off the discarding).  The critical thing 
> in my view is what the client is able to conclude.  If EXPIRED is returned,
> he may conclude that all of the associated stateids are gone (because of a 
> lease expiration), while with BAD_STATEID, he may only assume that the 
> stateid in question is gone, even if the precipitating event is a lease
> expiration.

Sounds good also (my server never does this), but I will note that maybe
adding to the definition of NFS4ERR_EXPIRED in Sec. 12 might
be a good idea to help clarify this? Something along the lines of:

	and all state for the clientid and associated stateids has
	been discarded by the server.

I have no idea if such editorial changes are still feasible?

> BTW, there seems to be a third intermediate case between the standard
> one (free all locks at lease expiration) and the "nice" one of just
> freeing the ones that conflict that seems like it might be a valid 
> choice.  That is, to keep the locks at lease expiration, but as soon
> as there is some conflict on any lock, to release all of them, rather
> than just the one in conflict.  If the client renewed the lease before
> any conflict occurred, he would be OK (as if no expiration happened),
> but if a conflict happend first, he would get EXPIRED (I believe) since
> the client can use this to know that all of the stateids associated
> with the locks are gone, which they would be in this case.  Comments?    

This is what my server does. It doesn't free state when a lease expires
(unless the state is "mouldy", ie. several hours->days since lease
 expiration), but does release all the state related to the client when
a conflict needs to be resolved and the lease expires. The only case
where my server frees state for a single stateid for a client, but retains the
other state for the client, is the one where the lease doesn't expire, but the
Recall of a delegation doesn't work. (And I believe that is the only case where
a correctly functioning client would get NFS4ERR_BADSTATEID returned from
my server.)

> I agree with this and don't forget NFS4ERR_ADMIN_REVOKED for those
> special occasions of administrator NFSv4 angst.

My server doesn't yet have an "admin tool". However, it seems that this
implies the revoked state will have to be retained, so that the server
can know to return this error instead of the others? (Not a problem,
imho, but an observation.)

> Oh yes, then NFS4ERR_CB_PATH_DOWN for the RENEW where the
> server knows or thinks there is a problem with the callback path.

Yep, I do that, too. I'll also note that, although I don't recall it being
mentioned in the RFC, that it would be really nice for a client to Return
all outstanding Delegations for that server ASAP. (Maybe a definition
for NFS4ERR_CB_PATH_DOWN could be added to Sec. 12 w.r.t this?)
Sec. 14.2.28 seems clear w.r.t. when NFS4ERR_CB_PATH_DOWN is returned,
but makes no mention of what a client might be expected to do for that
case?

Thanks go to both Dave and Spencer for the responses, rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 14 Apr 2004 01:02:41 -0500

<during the thread on EXPIRED and BAD_STATEID errors>

> I have no idea if such editorial changes are still feasible?

RFC3530 is what it is; changes can not be made in the RFC itself.

For error, errata can be submitted to the RFC editor and posted
to the RFC editor's errata pages.  I have an outstanding AI to
gather what has been mentioned to date and get that posted.

For interpretation items, the mailing list is the best place to start.
For large issues, like the ACL mapping, an informational RFC may
be appropriate.

Spencer