Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

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

> Surely you could keep around just enough clientid state to remember
the
> client reference bits for any clients associated with such remaining
> stateid's.  

Sure you could, but why?  You need the stateid information to tell
whether
any particular lock is in this expired state, and there is no way to 
determine when you can get rid of it.  With seesions I guess you could 
determine that EXPIRED was recieved by the client but not in v4.0.
In v4.0, you would have stateid that couldn't get rid of until the
client rebooted.  There would be no way to close it etc. since it is
invalid. 

> The memory required for that shouldn't be a great deal more
> than what's required just to hang on to the stateid.

My point is that it is no less.  You need the state information to 
determine the EXPIRED locks so what does this client information add? 

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 9:12 AM
To: Noveck, Dave
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

On Thu, Mar 09, 2006 at 08:19:13AM -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 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.

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

---

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

On Thu, Mar 09, 2006 at 09:40:19AM -0500, Noveck, Dave wrote:
> whether any particular lock is in this expired state, and there is no
> way to determine when you can get rid of it.

Is this really a problem just to return EXPIRED for any unknown stateid
referencing an unknown client?  Aside from the already-existing CLOSE
replay problem I can't see where this would cause trouble.  Maybe I'm
missing a case.

--b.