Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 9 Mar 2006 12:39:34 -0500

Exactly so.  If he holds onto the stateids that have not expired
he knows which ones to accept.  Other will get an error.  But,
to distinguish between those that have expiired and those that
were never valid, one would have to hold onto the expired ones
as well.  So it comes down to the value of informing the client
of that distinction, and except for a vague sense that that is
nicer, fiendlier, etc., I can't see what it is.  If a client has
a valid stateid and it becomes invalid, he nedds to deal with 
the consequences and I don't see where the consequences are
any different depending on the EXPITED/BAD_STATEID distinction.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 11:45 AM
To: Noveck, Dave
Cc: J. Bruce Fields; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

On Thu, 2006-03-09 at 08:19 -0500, Noveck, Dave wrote:
> You could do that in the case in which the server threw away all locks
> once the lease expired.  The spec allows another model, in which when
> the lease expires, you make the locks subject to revocation if there
> is a conflict.  In that case, you have the possibility of different
> stateid's having different expiration status, so that Trond's
technique
> would not be applicable.

Surely in that particular case, the server needs to hold onto all the
stateids that it hasn't expired anyway? The error only applies to those
stateids that are expired.

Cheers,
  Trond

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 10:00 PM
> To: Noveck, Dave
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID
> 
> 
> On Tue, Mar 07, 2006 at 08:02:45PM -0500, Noveck, Dave wrote:
> > 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.
> 
> 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.
> 
> _______________________________________________
> 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: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 Mar 2006 13:57:20 -0500

On Thu, Mar 09, 2006 at 12:39:34PM -0500, Noveck, Dave wrote:
> as well.

Well, sure, and the same is true for detecting stale clientid's.  If you
choose a stateid uniformly at random and throw it at our server it'll
return STALE_STATEID with probability nearly one.  I imagine the same is
true of most other servers.

We don't conclude from this that returning STALE_STATEID correctly is
impossible, because returning STALE_STATEID whenever it's needed is
quite easy (and useful), and the false positives (where we return it but
shouldn't) don't affect any important cases.  (Obviously, dealing with a
client that really sends stateid's that were never valid isn't a case
worth worrying about much.)

> So it comes down to the value of informing the client

The client finds out that its state has expired when we return EXPIRED,
and can attempt recovery if it wants.  BAD_STATEID doesn't always
necessarily mean that.

For example, BAD_STATEID can be returned to a replayed CLOSE, to certain
OPEN_CONFIRMs, etc., but if the client receives BAD_STATEID in such
cases, then it probably doesn't make sense for the client to try to
reclaim all its state.

(And I think the result of Trond's algorithm in these cases is OK--for
example it'll return either EXPIRED or BAD to the replayed CLOSE
depending on whether the client has expired or not, which will probably
allow the client to do the right thing.)

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Mar 2006 00:23:06 -0500

> any different depending on the EXPITED/BAD_STATEID distinction.

The difference is that if your client gets an NFS4ERR_EXPIRED, then it
immediately knows that it has to call SETCLIENTID instead of having to
probe using a RENEW call.

NFS4ERR_BAD_STATEID is described in section 8.1.3 as indicating "a logic
error on the part of the client or server". I can't see that to be the
case here.

Cheers,
  Trond