Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 9 Mar 2006 08:19:13 -0500

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.

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

---

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

> stateid's having different expiration status, so that Trond's technique

Surely you could keep around just enough clientid state to remember the
client reference bits for any clients associated with such remaining
stateid's.  The memory required for that shouldn't be a great deal more
than what's required just to hang on to the stateid.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Mar 2006 11:44:59 -0500

> stateid's having different expiration status, so that Trond's technique

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