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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 12 Apr 2004 14:58:15 -0700

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.

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Monday, April 12, 2004 4:13 PM
To: [email-masked]
Subject: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

Ok, so what about the following scenario:
- client has a delegation and is still able to do compounds on the server
- server attempts Recall of the delegation, which fails, presumably
  because the callback pathway has busted
  - after a timeout (mine is currently 5 * lease duration), the server
    discards the delegation and allows the conflicting request that
    caused the callback
- client uses stateid for discarded delegation
and the server would return NFS4ERR_BADSTATEID? (because, although it
had to discard the delegation, no lease expired)

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?

Sound right gang? rick

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

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 12 Apr 2004 20:18:17 -0500

> the stateid's associated with the lease were released, which also is

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.

> stateid in question is gone, even if the precipitating event is a lease

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