Subject: RE: lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt")

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

Mike Eisler wrote:
> [email-masked] wrote:
> > 
> > >>>>> "mre" == Mike Eisler <[email-masked]> writes:
> > 
> >     mre> Regarding,
> > 
> >     mre>    There are various
> >     mre>    scenarios involving server failure after such an event
> >     mre>    that require the storage of these lease expirations or
> >     mre>    network partitions.  One scenario is as follows:
> > 
> >     mre> Do we really want to require servers to do this?
> > 
> > Given the email exchange I just had with Dave Noveck (which should be
> > in the WG mail archive), I don't see that we have any choice.  Unless
> > the server records lease expirations in stable storage, we open up a
> > window which can lead to file corruption.

> Isn't this an issue with the NLM protocol for NFSv[23]?
> I.e., if the server reboots, and a client, due to network
> partition, fails to reclaim locks in the grace period, the
> same scenario can occur.

I believe it can happen.  I think the situation is exactly the
same as for V4.  If a client doesn't reclaim his lock within the
grace period (because of network partition), the server can grant
a conflicting lock to another client.  If that other client then
releases the conflicting lock, and there is another server reboot,
then if the network partition is healed, the original client will
get his lock back, without knowing that a conflicting lock was
granted to another client.  That makes honoring the reclaim erroneous.
At least it seems erroneous to me.

Is there anything in NLM/NSM that would prevent this?

> With NFSv4, a client that fails to renew within the grace period will
> either be told by the server that the client has lost its lease.

Something seems to be missing in the above sentence.  Either be
told ... or ???

> That's a situation no worse than NLM/NFSv[23] but one that
> doesn't have the baggage of the NLM Status Monitor.

The difference is that V4 aspires to be able to handle various
forms of mandatory locking.  In that context, the scenario in which
you have a lock and then reclaim it, while, in the interim someone
else had a conflicting lock (that allowed him to write where your 
lock would prevent him from writing), is much more troubling.

I think from a protocol point of view, V4 is able to deal with this
situation.  The server can figure out what is going on and record enough
information in stable storage to prevent erroneous reclaims.  Clearly
doing that is a good thing, but the question is how strictly should
the spec mandate that good behavior.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 19 Aug 2002 20:52:58 -0500

> At least it seems erroneous to me.

Stated so simply And I drew this cool ascii example. :-)

> Is there anything in NLM/NSM that would prevent this?

No.  There may have been this idea at one time but it was never
implemented.  The NSM protocol has an idea of server instance (as I
suggested in my email) but I don't believe it was fully integrated
into directing a client to abandon recovery because the server had
skipped past the client's view of the world (multiple server reboots).

> the spec mandate that good behavior.

Agreed.  My current opinion is that if the server is offering advisory
locking only, then it doesn't need to do the extra work.  If mandatory
locking is being used, then it should so something minimal as I
suggested and that burden shouldn't be too much greater than for
v2/v3.

-- 
Spencer