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

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 Aug 2002 12:46:05 -0700

I just don't understand how that scenario depends at all on the
fact that you are allowing locks to be held beyond the expiration
of the lease.

Scenario 1a:

     Client gets lock
     Lease expires -- lock stays aorund
     one second later -- Conflicting lock request 
     original client loses lock
     second client does an unlock
     server reboot
     First client reclaims his lock
     Server erroneously grants reclaim -- unless info in stable storage
         prevents that

Scenario 1b:

     Client gets lock
     Lease expires -- lock release
     one second later -- Conflicting lock request 
     second client does an unlock
     server reboot
     First client reclaims his lock
     Server erroneously grants reclaim -- unless info in stable storage
         prevents that

In the second case, the information is more limited in that you just
have the fact that the client as a whole has lost his locks, and there
is no question of recording individual locks.  However, the spec says
that even in the keep-expired-locks-around case, the server may choose 
to only record the fact that the client as whole has lost at least one 
lock.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 09, 2002 2:57 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: questions and comments on
draft-ietf-nfsv4-rfc3010bis-02-03.txt 

>>>>> "mre" == Mike Eisler <[email-masked]> writes:

    mre> Regarding,

    mre>    If the server continues to hold locks beyond the
    mre>    expiration of a client's lease, the server MUST employ a
    mre>    method of recording this fact in its stable storage.

    mre> I don't see what (though I vaguely recall understanding this
    mre> 3 years ago) holding the locks has to with the stable storage
    mre> requirement. Clarification is needed.

This is related to the scenario that appears a few more lines down in
the I-D.  The idea was to let the client recover its locks after a
network partition, as long as nobody else got a conflicting lock
during the partition.  The stable storage part comes in because the
server has to safely remember whether it granted any conflicting
locks.

mike

---

From: [email-masked]
Date: Fri, 09 Aug 2002 16:15:11 -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.
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'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 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

mike

---

From: David Robinson <[email-masked]>
Date: Mon, 12 Aug 2002 00:46:50 -0500

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

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.

	-David