Re: [nfsv4] more re: NFS4ERR_EXPIRED

Thomas.Talpey@netapp.com

Subject: Re: [nfsv4] more re: NFS4ERR_EXPIRED
Message-ID: <6.1.0.6.2.20040413131556.01cd2398@silver.nane.netapp.com>
From: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Date: Tue, 13 Apr 2004 10:27:23 -0700

Can someone clarify for me what recovery the client can/should
perform in the various cases we're describing? Do I read Dave
saying that EXPIRED might cause the client to invoke mass
recovery on all its stateids? This would be a pretty big incentive
to be careful with it!

I agree we should be much more explicit about CB_PATH_DOWN
in the doc. There are only two sentences on it in RFC3530, both
referring to the server's responsibility. In fact, since the server
is required to renew leases after returning this, it would seem
to be more of a buying-time thing than an error.

Tom.

At 12:43 PM 4/13/2004, rick@snowhite.cis.uoguelph.ca wrote:
>> 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
>nfsv4@ietf.org
>https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4