Re: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

spencer.shepler@sun.com

Message-Id: <D347DADC-8D6E-11D8-B69B-000A95DBCB70@sun.com>
From: Spencer Shepler <spencer.shepler@sun.com>
Subject: Re: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID
Date: Tue, 13 Apr 2004 12:20:13 -0500

On Apr 13, 2004, at 9:23 AM, Noveck, Dave wrote:

>> So you are partially describing the scenarios mentioned in
>> section 8.8 Server Revocation of Locks?
>
> Yes.  Those are the possibilities.
>
>> The server can be "nice" in that upon lease expiration it keeps some
>> of the state active and only releases that which has conflicting
>> requests.
>> In this case, I agree NFS4ERR_BAD_STATEID is the appropriate error.
>> However, if the server is not keeping partial, expired state then it
>> should
>> go ahead and return EXPIRED since it will be an additional burden
>> on the server to keep the extra information about just the state for
>> which
>> there was a conflict.
>
> I agree that the server should return EXPIRED in this case, but I
> disagree about the reason.
>
> There would be no additional burden to return BAD_STATEID as the
> "nice" server does.  That's because if the server simply deallocated
> all the state entries along with the locks, when the lease expired,
> any reference to the deallocated states would naturally result in
> BAD_STATEID, with no extra server effort.

Are you thinking of a particular server/stateid implementation here?
If so, maybe you could walk through some of the logical checks
that demonstrate the "no additional burden".  In the way the Solaris
server currently implements this, there is additional burden.

> The reason to return EXPIRED is that it avoids making the client
> probe each of stateids, when you could just tell him (via EXPIRED)
> that they all are gone, and save him the effort.  The client has
> to be prepared to probe all the stateids because servers may keep
> locks and only get rid of them when there is a conflict.  The
> limiting case is that the lease may expire, and there may then be
> individual conflicts with all of the locks within the lease and
> the client has to deal with that possibility.  So if the client
> is coded correctly, for the server to throw away all locks at
> lease expiration and return BAD_STATEID would work correctly.  It
> is just kind of anti-social to make him go to that extra effort
> when there is no possibility that there is the benefit of getting
> some of his locks back.

The client may choose to an implementation as you suggest.  It may
also choose an alternate path.  It isn't a requirement for the client
to probe everything upon receive of BAD_STATEID.

> 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?

Yes.  I agree that there is this third alternative and it is the 
easiest for
the server to implement; okay, next to just removing the state on lease
expiration.

Spencer

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