Subject: RE: Lease expiration behavior

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 19 Aug 2002 19:52:22 -0700

Spencer wrote: 
> On Mon, Noveck, Dave wrote:

 ... Stuff deleted ...
 
> > If one wants spec purity here, then I would limit the spec to the
> > following:
> > 
> >     If you have a lock and the lease has not expired, the server 
> >     MUST deny a conflicting lock.
> > 
> >     If you have a lock and the lease has expired, the server MUST
> >     grant a request for a conflicting and lock and MUST revoke
> >     yours.
> > 
> >     If you have a lock and the lease has expired, the server MAY
> >     (upon expiration or at any subsequent time while the lease
> >     remains in the expired state), revoke your lock.
> > 
> > Then the implementors' draft could discuss the implementation options,
> > including:
> > 
> >     A simple and reasonable implementation would be to free all locks
> >    associated with a client when its lease expires.

> How do we work in the idea of administrative intervention?  I think
> this will occur more often than we may plan based on the operational
> behavior for NFSv[23] that will carry over to NFSv4.  Of course, this
> is the case where the lease period has not expired and falls into the
> first requirement above? 

So modify the first requirement to be something like:

     If you have a lock (i.e. the client has obtaned it from the server
     and not released and the lease has not expired, and the server has
     not, due to some administrative action, revoked the lock within the
     lease period) the server MUST deny a conflicting lock.     

> This administrative action may be something
> as simple as unsharing/unexporting a filesystem at the server while
> all other filesystems are still active.  With the above, the server
> MUST revoke all state for the client on the single unshare.  Right?

With the first version, it really made no provision for the administrative
action and so essentially said the lock must not be released (bad!).
On the other hand, if the filesystem is unexported, it is hard to
see how anyone could try to get a conflicting lock (all he gets are
stale-filehandle errors) so I don't see how you could be prosecuted
for releasing the lock.  Dismissed for lack of evidence.

I think the spec should be very permissive regarding the effects of
administrative action.  Revoking all the state for the client on the
unshare seems a reasonable thing to do, but if someone should implement
things such that unexport followed by export (the oops-I-didn't-mean-to-
unexport case) should is a no-op if no client actually references a revoked
stateid before it is unrevoked (i.e. do it like the sophisticated case 
of expiration).

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 19 Aug 2002 22:10:40 -0500

>      lease period) the server MUST deny a conflicting lock.     

Looks reasonable.

> for releasing the lock.  Dismissed for lack of evidence.

Only used unexport as an easy example. :-)

> stateid before it is unrevoked (i.e. do it like the sophisticated case 

Agreed.

I was/am concerned that we rule out the instance where a server
command allows for release of state on a single file and that requires
all state at the client to be released.

I don't want to mislead the client implementor into thinking that
receiving a STALE_STATEID within the lease period is death to all
state.  It may be that the client's state for that single file has
been revoked and nothing else.

-- 
Spencer