Subject: [nfsv4] Detecting inconsistent state

From: [email-masked]
Date: Wed, 5 Jul 2006 15:58:32 -0400 (EDT)

Dear Puzzled (sorry, I couldn't resist:-)...
> One possiblity is that this is related to the following text that has
> always puzzled me:
> 
>     When the client determines the lease period may have expired, the
>     client must mark all locks held for the associated lease as 
>     "unvalidated". This means the client has been unable to re-establish
> 
>     or confirm the appropriate lock state with the server. As described 
>     in the previous section on crash recovery, there are scenarios in 
>     which the server may grant conflicting locks after the lease period 
>     has expired for a client. When it is possible that the lease period 
>     has expired, the client must validate each lock currently held to 
>     ensure that a conflicting lock has not been granted. The client may 
>     accomplish this task by issuing an I/O request, either a pending I/O
[cut here for brevity]

Just a guess, but I think this might have come from an early author
envisioning the use of leases as described by [Gray89]. From my recollection,
Cary Gray assumed that the client would notice that the lease had expired
when it was not successfully renewed, then assumed the worst and did
a "recovery" from that situation. (ie. It would not need a reply
like NFS4ERR_STALExxx or NFS4ERR_EXPIRED to tell it that it needed to
recover from an expired lease.)

Doing it this way has the advantage that you don't end up with weird edge
conditions, such as are described in Sec. 8.6.3 of RFC3530, because these
edge conditions stem from the fact that the client doesn't know it has lost
its lease/state. If the client always assumes it has lost its lease/state as
soon as it fails to renew within the lease interval, they don't occur.
However, this also implies that the client must go into "recovery" whenever
a short network partition, or similar, makes renewal fail. As such, it's
not as "fault tolerant" in mho.
As I recall, Cary Gray was using leases to deal with cache coherence, not
lock state, so the "recovery" wasn't nearly as painful.

Since everyone seems to have assumed that a client will go into "recovery"
after receiving an NFS4ERR_ from the server and RFC3530 deals with edga
conditions that result from that, I'd say that the stuff you were puzzled
about is "cruft" which everyone is pretty well ignoring?

Just my $0.00 worth, rick
[Gray89] Cary G. Gray and David R. Cheriton, "Leases: An Efficient Fault-
   Tolerant Mechanism for Distributed File Cache Consistency". In Proc.
   of the Twelfth ACM Symposium on Operating Systems Principals, Litchfield
   Park, AZ, Dec. 1989.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 6 Jul 2006 13:07:35 -0400

> Just my $0.00 worth, rick

But your answer makes sense, even there are no cents.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 3:59 PM
To: [email-masked]
Cc: Noveck, Dave
Subject: [nfsv4] Detecting inconsistent state

[cut here for brevity]

Just a guess, but I think this might have come from an early author
envisioning the use of leases as described by [Gray89]. From my
recollection,
Cary Gray assumed that the client would notice that the lease had
expired
when it was not successfully renewed, then assumed the worst and did
a "recovery" from that situation. (ie. It would not need a reply
like NFS4ERR_STALExxx or NFS4ERR_EXPIRED to tell it that it needed to
recover from an expired lease.)

Doing it this way has the advantage that you don't end up with weird
edge
conditions, such as are described in Sec. 8.6.3 of RFC3530, because
these
edge conditions stem from the fact that the client doesn't know it has
lost
its lease/state. If the client always assumes it has lost its
lease/state as
soon as it fails to renew within the lease interval, they don't occur.
However, this also implies that the client must go into "recovery"
whenever
a short network partition, or similar, makes renewal fail. As such, it's
not as "fault tolerant" in mho.
As I recall, Cary Gray was using leases to deal with cache coherence,
not
lock state, so the "recovery" wasn't nearly as painful.

Since everyone seems to have assumed that a client will go into
"recovery"
after receiving an NFS4ERR_ from the server and RFC3530 deals with edga
conditions that result from that, I'd say that the stuff you were
puzzled
about is "cruft" which everyone is pretty well ignoring?

Just my $0.00 worth, rick
[Gray89] Cary G. Gray and David R. Cheriton, "Leases: An Efficient
Fault-
   Tolerant Mechanism for Distributed File Cache Consistency". In Proc.
   of the Twelfth ACM Symposium on Operating Systems Principals,
Litchfield
   Park, AZ, Dec. 1989.