Subject: Re: [nfsv4] more re: NFS4ERR_EXPIRED

From: "Talpey, Thomas" <[email-masked]>
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, [email-masked] 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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/nfsv4

---

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

>  recovery on all its stateids? This would be a pretty big incentive

The recovery path the client chooses is its own.  Nothing is
prescribed in the RFC but one would likely expect that a reasonable
client may attempt to reopen files for which it held state at the
time of EXPIRED.  I don't remember specifically if there is suggestion
of how the client may make a reasonable choice about when to
reopen a file.

Things to consider from the client's perspective are things like:
were file locks ever held for the file, was the file ever modified by
the client, a delegation was held but no active opens by applications
were present at the client, etc.  Some clients may choose to be more
aggressive about their recovery patterns to deal with servers that
do not offer a grace period and will therefore respond to client
attempting to open files with CLAIM_PREVIOUS with the NO_GRACE
error.  The reason I mention that here, even though it is a
different scenario, is that it is similar to the case that a client's
lease has expired.

The server should attempt to do its best to avoid returning EXPIRED
but it can not guarantee to do so.

>  to be more of a buying-time thing than an error.

A renewal of a lease does not guarantee that the server will
still not choose to revoke a delegation.  It is not required to hold
the delegation forever; it should hold it for one lease period
and most likely it will be longer than that but it does need to
make forward progress and if the client is being stubborn about
returning a delegation (not making forward progress in the form
of flushing modified data for example) then it can revoke the
delegation and move on.

Spencer