Subject: Lease expiration behavior

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 19 Aug 2002 18:40:11 -0700

David Robinson wrote:
> [email-masked] wrote: 

> >>>>>>"Dave" == Dave Noveck <Noveck> writes: 
> >>>>>> 
> > 
> > Dave> I just don't understand how that scenario depends at all on 
> > Dave> the fact that you are allowing locks to be held beyond the 
> > Dave> expiration of the lease. 
> 
> > I'm not happy with the complexity introduced by letting servers hold 
> > onto locks after the lease expires, so I would not shed any tears if 
> > it were removed from the spec. 

> The root of this text is probably some text I had written many moons 
> ago on how an implementation may provide better service to a client 
> even after a lease expires. I don't think it needs to be in the spec 
> as it is really an implementation optimization issue. 

I agree with that.  However, when you say the following, I disagree
strongly.

> The spec should 
> only describe the standard behavior, if you are smart and do more 
> then it is up to you to make sure it conforms. 

Conforms to what?  If you have to conform to "standard behavior",
then you can't be smarter, or at least you can't act smarter.

If the spec describes, as required behavior, freeing all of the locks
upon expiration, then the clients would be written (validly) to assume
that behavior (e.g. if one of my locks is expired, then all of the locks
I had at the time are gone as well), and there would be no way that a 
server could restrict lock loss after expiration to the cases in which
it was required only by the existence of conflicting locks, no matter 
how smart the server or the implementor was.

Instead of describing some particular "standard" behavior, the spec 
should clearly state the requirements (and non-requirements) for 
acceptable server behavior, and let the implementation make its 
choice as long as it is within the boundaries.
 
> As another example, 
> the server could log all locking state to stable storage which would 
> allow it to never cause clients to perform recovery, there are 
> probably some subtle implications on how to implement this, but it 
> too should be excluded from the spec. 

Sure, but let's be clear on the differences between this case and
the previous one.  In this case, a client sees or doesn't see a "server 
reboot" and when he sees that event (stale-clientid or stale-stateid
errors), all of his locks are gone.  The server may arrange things so 
that that event never happens or happens very infrequently (e.g. only 
when a particular sort of battery failure occurs, or when a particular
sort of media error occurs, and not on a "normal" reboot), but there
is no change in the rules that the client depends on.

In the previous example, there is a client-perceptible difference
between servers that free all locks on lease expiration and those
that do not, and if the clients assume the first sort of behavior,
they may not work with servers that have the second sort of behavior.
Of course, clients should not assume the second sort of behavior
(e.g. that locks will stay around unless there is a conflict), but 
it would be harder for them to erroneously depend on that since
normally clients can't make assumptions about what conflicting locks
other clients are requesting.

> Limit the spec to standard behavior required for functionality, 
> holding locks beyond the lease interval is not one. The phantom 
> implementors draft is a better place for such a thing. 

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.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 19 Aug 2002 21:08:42 -0500

> choice as long as it is within the boundaries.

I might point out that we need to include in this discussion the
scenario of administrator release of locking state.  As the
specification suggests, the server implementation may provide for an
administrative release of open/file-locking state for an individual
file or subset of files for which the client has state.

I know that the above was an example of spec language but we shouldn't
require the release of all state for a "simple" administrative
intervention.

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

-- 
Spencer