From: mike.kupfer@sun.com
Date: 08/20/02-04:09:08 PM Z
Message-Id: <200208202109.g7KL99XE197848@athyra.eng.sun.com> From: mike.kupfer@sun.com Subject: Re: Issue 05 was (lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt") Date: Tue, 20 Aug 2002 14:09:08 -0700 After digesting the flurry of mail on this topic, here are my thoughts: - I think that using the NLM/NSM protocols as a standard is setting the bar a bit low. On the other hand, I guess they provide us with enough operational experience to conclude that incorrect lock reclaims are not a big problem in practice. - I don't understand why the problem should be considered more severe when the server implements mandatory locking. It's not like the application gets to choose which model (mandatory or advisory) the server is using, or even detect reliably which model the server is using. - Spencer wrote > I don't want to mislead the client implementor into thinking that > receiving a STALE_STATEID within the lease period is death to all > state. It may be that the client's state for that single file has > been revoked and nothing else. Is this a statement that the client needs to handle STALE_STATEID differently, depending on whether it thinks it still has an unexpired lease? That would be a pretty major departure from how STALE_STATEID is currently dealt with in the spec. - I didn't see consensus on either of the following two issues: - administrative commands and their impact on client recovery - what the spec should say about stable storage and lock recovery I doubt that the Last Call period is long enough to make the necessary changes to provide single-file recovery (to support administrative commands). I think this is an issue that should be deferred. I guess the stable storage issue is small enough (given the history we have with NLM/NSM) that it can be deferred. On the other hand, given that we know about the issue and that the consequences are pretty severe (file corruption), I don't see how v4 can get past Proposed Standard until this is addressed. I'm willing to let others with a better understanding of IETF policies and politics make the call on what to do here. mike
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:15 AM Z CST