Subject: RE: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 13 Apr 2004 07:23:00 -0700

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

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.

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?    

> Just having the server correctly return EXPIRED
> is a big step in any case. ;-)

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Monday, April 12, 2004 9:18 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

On Apr 12, 2004, at 4:58 PM, Noveck, Dave wrote:

> Excellent example and question.  Here's my take.
>
>> - client uses stateid for discarded delegation
>> and the server would return NFS4ERR_BADSTATEID? (because, although it
>> had to discard the delegation, no lease expired)
>
> 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.

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

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

>
>> On the other hand, if the delegation was discarded because the lease
>> expired (both network paths were partitioned), the error returned
>> when
>> - client uses stateid for discarded delegation
>> would be NFS4ERR_EXPIRED?
>
> 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.
>
> 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.

So you are partially describing the scenarios mentioned in
section 8.8 Server Revocation of Locks?

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.  Just having the server correctly return EXPIRED
is a big step in any case. ;-)

Spencer

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 13 Apr 2004 12:20:13 -0500

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

> when there is no possibility that there is the benefit of getting

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.

> 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