Subject: RE: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.t xt

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 Aug 2002 20:40:38 -0700

> >>>>> "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.
> 
> You raise a good point.  As long as the spec lets the server hold
> locks beyond the expiration of the lease (and the client has no way of
> telling whether the server takes advantage of that), it appears that
> the server must record lease expiration information in stable storage.

That's not my point.  My point is that the server must record lease
expiration information in stable storage whether the spec lets the
server hold locks beyond the expiration of the lease or not.

> If the client knew that the locks had to be dropped (either because
> the spec required it or the server told it that that's what the server
> will do), then when the client realizes that the lease has expired, it
> will not try to reclaim its locks.

I don't see that the client has enough infomration to make the 
distinction you want to make, unless you are prepared to adhere to it
so strictly that essentially locks could never be reclaimed.

Look at the following sequence of events, as seen from the client.
Suppose the lease period is 50.

At t, client gets a lock.

At t+40, it sends a renew.  No response.

It keeps sending (UDP) or not (TCP) but in any
case, possibly after one or more connecion breaks,
it gets back a STALE_CLIENTID error, at t+100.

Can the client reclaim his locks?  I would expect that
he can and if he can't in that situation, when could 
he ever reclaim them?  The most likely scenario of what
happened is that sometime between t and t+40, the server
went down, rebooted and was back up at t+100.

I suppose that if the server rebooted and was back up by t+50,
then the client could know that his lease could not have expired,
but I think this would be an unusual case, and so I don't think
you can make reclaim conditional on it.

But if we have the situation above, then we can certainly 
have a case in which after t+50, the locks are released,
someone else gets and releases a conflicting lock at
t+51 and t+52 respectively, and everything is the same from
our client's point of view.  The client does not have the 
information to decide if he may reclaim (even if you trusted
him).  The server has that information, if he keeps it in
stable storage.

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

But there would be no real simplification in the spec.  If you don't
want to implement this, you don't have to and I don't think it adds
complexity for those that don't impleemnt it.

> But it seems like the client has to be careful about detecting lease
> expiration, to avoid the following scenario:
> 
>     Client gets lock
>     Client submits RENEW request on time, but it gets delayed (e.g.,
>         network congestion)
>     Lease expires -- lock release
>     one second later -- Conflicting lock request 
>     second client does an unlock
>     server reboot
>     First client retransmits RENEW request and gets STALE_CLIENTID
>         from server
>     First client reclaims his lock
>     Server erroneously grants reclaim

Exactly the scenario, but, there is no reasonable degree of care
that the client can exercise to avoid this.  Take away the omniscient
narrator, and let the client tell his story:  "I got a lock.  I
submitted a renew request on time.  Then later I got a STALE_CLIENTID
error.  Then I did a reclaim.  What was I supposed to do?"  Is this a 
case of justified reclaim or should we take him downtown and beat a 
confession out of him?

---

From: [email-masked]
Date: Fri, 09 Aug 2002 22:30:57 -0700

>>>>> "Dave" == Dave Noveck <Noveck> writes:

    Dave> The client does not have the information to decide if he may
    Dave> reclaim (even if you trusted him).  The server has that
    Dave> information, if he keeps it in stable storage.

You're right.  The way I had envisioned it, any time the server goes
down the client would *have* to assume that it lost its lock.  Which
obviously wouldn't work well in practice...

    Dave> the server must record lease expiration information in
    Dave> stable storage whether the spec lets the server hold locks
    Dave> beyond the expiration of the lease or not.

So it needs to record the loss of the lease, and it needs to commit
that to stable storage before granting any conflicting locks.  Are
there any other implementation guidelines?  Do we need to say how long
that information has to stay on stable storage?

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

    Dave> But there would be no real simplification in the spec.  If
    Dave> you don't want to implement this, you don't have to and I
    Dave> don't think it adds complexity for those that don't
    Dave> impleemnt it.

Actually, I was thinking about the complexity in terms of reasoning
about correctness.  But given that the server has to record
expirations onto stable storage anyway, I agree that letting the
server hold onto locks after lease expiration doesn't make things all
that more complicated.

mike