Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 7 Mar 2006 20:02:45 -0500

> Well, the specification is vague enough to allow both but I prefer
> that the server return _EXPIRED in the cases where all of the client's 
> state is expired so that it has a better chance of recovering.

I know it is nicer, in that gives the client more of a sense of what 
happened, to return EXPIRED when you can, but if the client is supposed
to recover in the face of either, why does he have a better chance of
recovering with EXPIRED?

The issue that prevents you requiring EXPIRED is that there is no way
to bound the time for which you would have to save EXPIRED stateid's.
At some point, you have to stop saving that information and the client
will get BAD_STATEID.  Otherwise, you would have to keep such information
for unbounded length of time.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Tuesday, March 07, 2006 6:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

On Tue, [email-masked] wrote:
> For the following scenario:
> 	Client A - holds write lock on byte 0 of foo, gets StateidAfoo
> 	Client A - is network partitioned from server
> 	Client B - gets write lock on byte 0 of foo after Client A lease
> 		expires, with StateidBfoo
> 	- network partition for Client A heals
> 	Now, when Client A attempts to use the StateidAfoo, what should
> 	the server return?
> 
> At Connectathon06, some servers returned NFS4ERR_EXPIRED and others
> returned NFS4ERR_BAD_STATEID. Can either error be used for this case?
> (If so, I need to tweak my client to handle both.)

Well, the specification is vague enough to allow both but I prefer
that the server return _EXPIRED in the cases where all of the client's 
state is expired so that it has a better chance of recovering.

There is text that would lead one to believe that _BAD_STATEID
should be returned if the client's lease has NOT expired and the
client has just chosen to use a stateid that is not valid.  This
is of course different than returning _OLD_STATEID.  The sections
that I am thinking of are 6.1.3 and 6.10.1.

In summary, the client needs to be prepared for both and in general
the server should more often than not return _EXPIRED.

Spencer

_______________________________________________
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: Wed, 8 Mar 2006 20:40:42 -0600

> to recover in the face of either, why does he have a better chance of

Well, let's see.  If the client receives EXPIRED it knows that everything
for that server is gone and it can start a top down recovery
of the state.  Otherwise, the client does the recovery piece-meal
or insert extra logic to do RENEW.

Yes, client has to be prepared for both but if there is a choice...

> for unbounded length of time.

If there is a choice...  Yes, I agree with what you are saying but
wanted to give guidance to a server implementor that if the information
was available to return one over the other there was a preference.

Spencer

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 8 Mar 2006 21:59:50 -0500

> for unbounded length of time.

I think Trond suggested at some point devoting 32 bits of the stateid to
a client reference--some set of bits that uniquely identify a client per
stateid.  You could use unix time for the first setclientid from the
client (with a bit of fudging to guarantee uniqueness) and then it would
double to detect STALE stateid's.

Then you could return expired for any stateid from the current server
boot instance with a client reference that doesn't refer to any current
client.  Right?

--b.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 09 Mar 2006 08:01:41 -0500

At 09:59 PM 3/8/2006, J. Bruce Fields wrote:
>stateid.

Great idea, but 32 bits is maybe awkward since the clientid is 64. As a
server implementation decision though it could work fine, as long as its
clientid's only used a subset of the bits. Then it could stick that value
in as something of an index.

If we promoted this to a protocol spec, there would be only 32 bits left
over for other server state, and besides the structure is defined as opaque
to the client. So that sounds like a bad idea.

I'll also point out that the sessionid in many ways replaces the clientid
altogether (since a session always implies a clientid). The session would
provide context for each op, so the extra baggage really doesn't need to
be in the stateid payload at all, when a session is established.

Tom.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 Mar 2006 09:05:28 -0500

On Thu, Mar 09, 2006 at 08:01:41AM -0500, Talpey, Thomas wrote:
> If we promoted this to a protocol spec

There'd be no reason to do that; though if we worked out the details it
might be worth including it as an implementation hint.

--b.

> , there would be only 32 bits left