Subject: questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt

From: Mike Eisler <[email-masked]>
Date: Sun, 11 Aug 2002 16:17:09 -0700

questions on "draft-ietf-nfsv4-rfc3010bis-02-04.txt" 

Regarding,

   The server must be able to distinguish the following situations and
   return the error as specified:

   o    The stateid was generated by an earlier server instance (i.e.
        before a server reboot).  The error NFS4ERR_STALE_STATEID should
        be returned.

   o    The stateid was generated by the current server instance but the
        stateid no longer designates the current locking state for the
        lockowner-file pair in question (i.e. one or more locking
        operations has occurred).  The error NFS4ERR_OLD_STATEID should
        be returned.

        This error condition will only occur when the client issues a
        locking request which changes a stateid while an I/O request
        that uses that stateid is outstanding.

So which op, the I/O or the locking op gets the error?
And why should any error be returned at all?

Regarding,

 There are various
   scenarios involving server failure after such an event that require
   the storage of these lease expirations or network partitions.  One
   scenario is as follows:

Do we really want to require servers to do this?

Regarding,

   The third lock revocation event can occur as a result of
   administrative intervention within the lease period.  While this is
   considered a rare event, it is possible that the server's
   administrator has decided to release or revoke a particular lock held
   by the client.  As a result of revocation, the client will receive an
   error of NFS4ERR_EXPIRED and the error is received within the lease
   period for the lock.  In this instance the client may assume that
   only the lock_owner's locks have been lost.  The client notifies the
   lock holder appropriately.  The client may not assume the lease
   period has been renewed as a result of failed operation.

It seems difficult for the client to distinguish this type of
expiration from a an expiration where all its leased state has expired.

Regarding,

   The LOOKUP operation will return a filehandle without establishing
   any lock state on the server.  Without a valid stateid, the server
   will assume the client has the least access.  For example, a file
   opened with deny READ/WRITE cannot be accessed using a filehandle
   obtained through LOOKUP because it would not have a valid stateid
   (i.e. using a stateid of all bits 0 or all bits 1).

This at odds with the READ and WRITE desciptions, and it suggests that
special stateids are without use.

Regarding,

     The definition of the "tag" in the request is left to the
     implementor.  It may be used to summarize the content of the
     callback compound request for the benefit of packet sniffers and
     engineers debugging implementations.  However, the value of "tag"
     in the response MUST be the same value as provided in the request.

and

     The definition of the "tag" in the request is left to the
     implementor.  It may be used to summarize the content of the
     compound request for the benefit of packet sniffers and engineers
     debugging implementations.  However, the value of "tag" in the
     response SHOULD be the same value as provided in the request.

which is it, MUST or SHOULD? Also, I suggest the paragraph appear in
one place, not two, and I suggest its single place be in
section 14 with the COMPOUND procedure description.

Regarding,

     Some servers may only support locking for byte offsets that fit
     within 32 bits.  If the client specifies a range that includes a
     byte beyond the last byte offset of the the 32-bit range, but does
     not include the last byte offset of the 32-bit and all of the byte
     offsets beyond it, up to the end of the valid 64-bit range, such a
     32-bit server MUST return the error NFS4ERR_BAD_RANGE.

I don't understand what the above is saying.

Regarding,

     The rflags returned by a successful OPEN allow the server to return
     information governing how the open file is to be handled.
     OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
     OPEN_CONFIRM operation before using the open file.
     OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
     behavior is Posix like with respect to lock range coalescing.  From
     this the client can choose to manage file locking state in a way to
     handle a mis-match of file locking management.

Presumably if OPEN created a file, requeswts an OPEN_CONFIRM, and
the OPEN_CONFIRM never arrives, the file stays created right?

---

From: Spencer Shepler <[email-masked]>
Date: Sun, 11 Aug 2002 22:15:28 -0500

> section 14 with the COMPOUND procedure description.

"SHOULD" and I have removed the second occurance of the description as
suggested.

> the OPEN_CONFIRM never arrives, the file stays created right?

Yes.  This has been my assumption all along.  Clarification?

Spencer

---

From: [email-masked]
Date: Mon, 12 Aug 2002 13:08:26 -0700

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

    mre> Regarding,

    mre>      Some servers may only support locking for byte offsets
    mre>      that fit within 32 bits.  If the client specifies a
    mre>      range that includes a byte beyond the last byte offset
    mre>      of the the 32-bit range, but does not include the last
    mre>      byte offset of the 32-bit and all of the byte offsets
    mre>      beyond it, up to the end of the valid 64-bit range, such
    mre>      a 32-bit server MUST return the error NFS4ERR_BAD_RANGE.

    mre> I don't understand what the above is saying.

Let MAX32=0xffffffff.  If the client specifies a range that starts
after MAX32, a 32-bit server must return BAD_RANGE.  If the client
specifies a range that ends after MAX32 but before MAX64 ("end of
file"), a 32-bit server must return BAD_RANGE.

mike

---

From: [email-masked]
Date: Mon, 12 Aug 2002 13:16:20 -0700

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.

mike

---

From: Mike Eisler <[email-masked]>
Date: Mon, 19 Aug 2002 16:01:19 -0700

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

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.
That's a situation no worse than NLM/NFSv[23] but one that
doesn't have the baggage of the NLM Status Monitor.

	-mre

---

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

> partition, fails to reclaim locks in the grace period, the

Yes.  And NFSv[23] provides advisory locking.  I suppose we need to
decide how badly we want to require the server to store lease
expiration/locking state and at what level (a MUST or implementation
suggestions)

> doesn't have the baggage of the NLM Status Monitor.

For single server failure, you are correct.  

I believe the most interesting scearnio would be when the server has
cascading failures and during the first grace period there is a
network partition for the first client.  For the example below, assume
mandatory locking is being used to add some degree of guarantee to the
mix.

-------------------------------

Client A			Server-(instance)	Client B
--------			------			--------
				(server-1)
LOCK(fileA)	->
		<-		OKAY
READ(fileA)	->
		<-		OKAY
				(reboot)
				(server-2)
				(grace starts)
RENEW -> | network partition |
				(grace ends)
						<-	LOCK(fileA)
				OKAY		->
						<-	READ(fileA)
RENEW -> | network partition |	OKAY		->
						<-	WRITE(fileA)
				OKAY		->
						<-	UNLOCK(fileA)
				(reboot)
				(server-3)
				(grace starts)
	 | partition ends |
RENEW 		-> 
		<-		STALE_CLIENTID
LOCK(fileA)	-> (recovery)
		<-		OKAY
WRITE(fileA)	->
		<-		OKAY

-------------------------------

As mentioned above, we have to decide, from a big picture view, how
much we want to solve as protocol implementation requirements
vs. treat as quality of server implementation issues.  In essence, do
we think that this failure scenario will be any worse than it is with
NFSv[23].  Have we set a different goal for NFSv4 and file locking
than exists for v2/v3?  With NFSv4, file locking could be reliable
enough for applications to use it where there has been reluctance for
use with v2/v3.  Our solve the failure scenario above may be enough to
keep applications from using NFSv4 file locking.  Anyway, on to the
potential solutions.

In the example above, the lease for Client A doesn't expire while the
server is up.  The client thinks that the server has just been down a
long time (when it actually has been a network partition).  

It has been suggested that Client A could check the modification time
of the file to see if a conflict has occurred.  However, it was
pointed out that non-overlapping locking regions can lead to
false-positives with this test.  We could choose to be happy with this
solution based on our assumptions about applications that use
sub-range file locking.

If the server were to record information on stable storage, what is
the minimum information?  

1) In the case that the lease expires before the first server failure,
the server just records the clientid and expiration event in stable
storage.  Next time the client attempts to recover, the server rejects
all requests related to recovery for that client.

2) In the case above where the lease has not expired before the server
failure...
   The minimum information would be the clientid and the last time the
client held locking state as compared to the server's last
instantiation.  With this basic information, the server can track that
the client had not recovered during the second server instance.  From
this, the server can just refuse Client A's attempt to recover during
the third server instance (server-3) assuming that a conflict
occurred.  This is the harshest decision from the server but it is the
safest.  This solution doesn't account for the partial recovery during
the server-2 instance.

Of course, the server could save all state information to stable
storage but this would be the same as the server not failing at
all. :-)

In the current NFSv[23] solution, the server tracks the client's name
so that it can notify the client when the server reboots.

So items 1) and 2) are similar to today's solution for v2/v3.  Is the
combination of these solutions acceptable for implementation and
protocol correctness?  I am assuming that this stable storage
requirement only applies to file locking state and not open or
delegation state.

The above discussion only deals with the instance where the server is
not allowing state beyond the lease expiration period.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Mon, 19 Aug 2002 23:06:13 -0700

> mandatory locking is being used to add some degree of guarantee to the

The above is an outstanding example. I was about to respond to Dave N. and
Mike K. that the lease expiration during server instance scenario
mandated either stable storage or the server return NFS4ERR_NO_GRACE
on each post server-reboot reclaim, and then I read your email.

...
> safest.  This solution doesn't account for the partial recovery during

I agree with above. However, I'm not sure we can prove that there isn't
a third case that requires even more information. So, in lieu of
recording all state to stable storage, or in lieu of a
proof that less than all state to stable storage suffices,
the server's only recourse is to return NFS4ERR_NO_GRACE to any
post-server-reboot reclaim request.

>[...]

Understood.

As Dave N and Spencer discussed in related messages today,
there is the issue of how to deal with locks revoked via
administrative action. I don't know what the solution
is, but I suspect that one part of the solution is 
creating a new error code that tells the client that
administrative action has resulted in lock revocation.
This way, as Spencer wrote, the client can distinguish
between all its locks being lost from a smaller granularity
of loss, such as all the locks and share reservations for
a particular lock owner. BTW, I did raise this
issue in:

http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0541.html

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 20 Aug 2002 02:20:48 -0500

> post-server-reboot reclaim request.

I am not sure what you are suggesting with respect to what conditions
the server will return NO_GRACE.  There is the obvious, client
attempts reclaim and server is beyond grace period.  But under what
scenarios of server reboot other than this would NO_GRACE be returned?

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Mon, 19 Aug 2002 23:35:31 -0700

> scenarios of server reboot other than this would NO_GRACE be returned?

Any of the following (which apply to after server reboot):

	- Server does not record anything inforation about lease expirations or
		the time the clients last held lock state.

	- Any other scenario other than the two you've mentioned that requires
		state in addition to what you've mentioned. I can't prove (yet anyway)
		this scenario exists, but neither do I have any proof it
		this scenarion does not exist.

	- The server's records in stable storage have been corrupted or damaged.

		-mre

---

From: [email-masked]
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

---

From: Mike Eisler <[email-masked]>
Date: Tue, 20 Aug 2002 18:25:28 -0700

>   reclaims are not a big problem in practice.

I agree NLM/NSM sets the bar to low. We also don't want
NFSv4 to set a lower standard. Please chalk up my earlier
attempt to draw a parallel with NLM/NSM as temporary
insanity; I've taken my lithium now, and am all better.

>   server is using, or even detect reliably which model the server is

I tend to agree that mandatory vs. advisory is orthogonal
to this issue. Mandatory locking ultimately requires cooperation
at the application level (otherwise there are trivial DoS attacks),
so ultimately, mandatory locking is effectively advisory.

As for the application getting to choose the model, I hope
I've finally gotten the specification to make it clear that
apps operating in a POSIX model do get to choose this model
(if the server allows it) vis the mandatory lock bit of
the mode attribute, and that the server does return the
right error codes to indicate that mandatory locking is on.

>   - administrative commands and their impact on client recovery

I see consensus that administrative command revocation of
locks is a requirement, and I think there's consensus that
what is specified today is not tight enough.

>   administrative commands).  I think this is an issue that should be

I take a stab at it below.

>   make the call on what to do here.

I don't think it can be deferred. We've learned that lock state requires
stable storage in order for recovery from server reboots to work.
We should specify that the server that implements the grace period
MUST record state, otherwise it MUST return _NO_GRACE on reclaim
attempts.

Here are my proposed edits for closing off this issue (as usuall
there are probably typos):

CHANGE (in section 8.6.3 Network Partitions and Recovery):

   If the server continues to hold locks beyond the expiration of a
   client's lease, the server MUST employ a method of recording this
   fact in its stable storage.  Conflicting lock requests from another
   client may be serviced after the lease expiration.  There are various
   scenarios involving server failure after such an event that require
   the storage of these lease expirations or network partitions.  One
   scenario is as follows:

        A client holds a lock at the server and encounters a
        network partition and is unable to renew the associated
        lease.  A second client obtains a conflicting lock and then
        frees the lock.  After the unlock request by the second
        client, the server reboots or reinitializes.  Once the
        server recovers, the network partition heals and the
        original client attempts to reclaim the original lock.

   In this scenario and without any state information, the server will
   allow the reclaim and the client will be in an inconsistent state
   because the server or the client has no knowledge of the conflicting
   lock.

   The server may choose to store this lease expiration or network
   partitioning state in a way that will only identify the client as a
   whole.  Note that this may potentially lead to lock reclaims being
   denied unnecessarily because of a mix of conflicting and non-
   conflicting locks.  The server may also choose to store information
   about each lock that has an expired lease with an associated
   conflicting lock.  The choice of the amount and type of state
   information that is stored is left to the implementor.  In any case,
   the server must have enough state information to enable correct
   recovery from multiple partitions and multiple server failures.

TO:

   When a network partition is combined with a server
   reboot, there are edge conditions that place requirements
   on the server in order to avoid silent data corruption
   following a server reboot. Two of these edge conditions
   are known, and are discussed below.

   The first edge condition has the following scenario:

     1. Client A acquires a lock.

     2. Client A and server experience mutual network partition, such
        that client A is unable to renew its lease.

     3. Client A's lease expires, so server releases lock.

     4. Client B acquires a lock that would have conflicted
        with that of Client A.

     5. Client B releases the lock

     6. Server reboots

     7. Network partition between client A and server heals.

     8. Client A issues a RENEW operation, and gets back a 
	NFS4ERR_STALE_CLIENTID.

     9. Client A reclaims its lock within the server's grace period.

   Thus, at the final step, the server has erroneously
   granted client A's lock reclaim. If client B modified
   the object the lock was protecting, client A will
   experience object corruption.

   The second known edge condition follows:

     1. Client A acquires a lock.

     2. Server reboots.

     3. Client A and server experience mutual network
        partition, such that client A is unable to reclaim
        its lock within the grace period.

     4. Server's reclaim grace period ends. Client A has no locks
        recorded on server.

     5. Client B acquires a lock that would have conflicted
        with that of Client A.

     6. Client B releases the lock

     7. Server reboots a second time

     8. Network partition between client A and server heals.

     9. Client A issues a RENEW operation, and gets back a 
	NFS4ERR_STALE_CLIENTID.

     10.Client A reclaims its lock within the server's grace period.

   As with the first edge condition, the final step of the scenario of
   second edge condition has the server erroneously granting client A's
   lock reclaim.

   Solving the first and second edge conditions requires
   that the server either assume after it reboots that edge
   condition occurs, and thus return NFS4ERR_NO_GRACE for
   all reclaim attempts, or that the server record some
   information stable storage.  The amount of information
   the server records in stable storage is in inverse
   proportion to how harsh the server wants to be whenever
   the edge conditions occur. The server that is completely
   tolerant of all edge conditions will record in stable
   storage every lock that is acquired, removing the
   lock record from stable storage only when the lock
   is unlocked by the client and the lock's lockowner
   advances the sequence number such that the lock release
   is not the last stateful event for the lockowner's
   sequence. For the two aforementioned edge conditions,
   the harshest a server can be, and still support a grace
   period for reclaims, requires that the server record in
   stable storage information for each client containing the
   client's id string, a boolean that indicates if the
   client's lease expired or if there was administrative
   intervention (see the section, Server Revocation of Locks)
   to revoke a record lock, share reservation,
   or delegation, and a timestamp of the last time the
   client held locking state. The server also records in
   the stable storage the timestamps from the two most
   recent server reboots.

   For the first edge condition, after the server reboots,
   the record that client A's lease expired means that
   another client could have acquired a conflicting lock,
   so the server must reject a reclaim from client A with
   the error NFS4ERR_NO_GRACE.

   For the second edge condition, after the server reboots
   for a second time, the record that the client had an
   unexpired lock established before the server's previous
   incarnation means that the server must reject a reclaim
   from client A with the error NFS4ERR_NO_GRACE.

   Therefore, the server MUST implement one of the
   following strategies (which apply to reclaims of
   share reservations, record locks, and delegations):

   1. Reject all reclaims with NFS4ERR_NO_GRACE. This
      is superharsh, but necessary if the server does not
      want to record lock state in stable storage.

   2. Record sufficient state in stable storage such that
      all known edge conditions involving server reboot,
      including the two noted in this section, are
      detected. False positives are acceptable. Note that
      at this time, it is not known if there are other
      edge conditions.

      In the event, after a server reboot, the server determines
      that there is unrecoverable damage or corruption to the
      the stable storage, then for all clients and/or locks
      affected, the server MUST return NFS4ERR_NO_GRACE.

  A mandate for the client's handling of the
  NFS4ERR_NO_GRACE error is outside the scope of this
  specification, since the strategies for such handling
  are very dependent on the client's operating environment.
  However, one potential approach is described below.

  When the`client receives NFS4ERR_NO_GRACE, it could
  examine the change attribute of the objects the
  client is trying to reclaim state for, and use that to
  determine whether to re-establish the state via normal
  OPEN or LOCK requests. This is acceptable provided the
  client's operating environment allows it.  In otherwords,
  the client implementor is advised to document for his
  users the behavior. The client could also inform the
  application that its record lock or share reservations
  (whether they were delegated or not) have been lost,
  such as via a UNIX signal, a GUI pop-up window, etc. See
  the section, "Data Caching and Revocation" for a discussion
  of what the client should do for dealing with unreclaimed delegations
  on client state.

CHANGE (in section 8.8., Server Revocation of Locks)

TO:

   error of NFS4ERR_ADMIN_REVOKED and the error is received within the lease

CHANGE:

   NFS4ERR_ATTRNOTSUPP   An attribute specified is not supported by the
                         server.  Does not apply to the GETATTR
                         operation.

TO:

   NFS4ERR_ATTRNOTSUPP   An attribute specified is not supported by the
                         server.  Does not apply to the GETATTR
                         operation.

   NFS4ERR_ADMIN_REVOKED Due to administrator intervention,
			 the lockowner's record locks,
			 share reservations, and
			 delegations have been revoked by
			 the server.

CHANGE: (to all procedures and operations in sections 14 and 15 that return
	NFS4ERR_EXPIRED)

   ERRORS

TO:

   ERRORS

     NFS4ERR_ADMIN_REVOKED

CHANGE: (in section 18)

           NFS4ERR_DEADLOCK        = 10045,/* file locking deadlock   */
           NFS4ERR_FILE_OPEN       = 10046 /* open file blocks op.    */
   };

TO:

           NFS4ERR_DEADLOCK        = 10045,/* file locking deadlock   */
           NFS4ERR_FILE_OPEN       = 10046,/* open file blocks op.    */
           NFS4ERR_ADMIN_REVOKED   = 10047,/* lockowner state revoked */
   };

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 20 Aug 2002 22:00:53 -0500

>   STALE_STATEID is currently dealt with in the spec.

Actually, section 8.8 discusses the administrative release of state
and says that the client will receive NFS4ERR_EXPIRED.  It then goes
on to discuss the recovery the client would employ to determine if
other locking state may have been lost.  All of this assumes that
_EXPIRED was received within the lease period.

Mike's suggested text changes address this section of the
specification.

>   administrative commands).  I think this is an issue that should be

We have two weeks left in the last call period.  An attempt should be
made to resolve the issue as best we can.

-- 
Spencer

---

From: [email-masked]
Date: Wed, 21 Aug 2002 11:53:48 -0700

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

    mre> As for the application getting to choose the model, I hope
    mre> I've finally gotten the specification to make it clear that
    mre> apps operating in a POSIX model do get to choose this model
    mre> (if the server allows it) vis the mandatory lock bit of the
    mre> mode attribute, and that the server does return the right
    mre> error codes to indicate that mandatory locking is on.

Well, the application still doesn't know whether the server will
actually honor the mandatory lock bit.  On the other hand, as Dave
N. pointed out, the application supplier can specify that if NFS is
used, the server must support mandatory locking.  So I'm satisfied on
that issue.

    >> administrative commands).  I think this is an issue that should
    >> be deferred.

    mre> I take a stab at it below.

Modulo some wordsmithing and one technical concern, I'm happy with
your text.

    mre>    For the two
    mre>    aforementioned edge conditions, the harshest a server can
    mre>    be, and still support a grace period for reclaims,
    mre>    requires that the server record in stable storage
    mre>    information for each client containing the client's id
    mre>    string, a boolean that indicates if the client's lease
    mre>    expired or if there was administrative intervention (see
    mre>    the section, Server Revocation of Locks) to revoke a
    mre>    record lock, share reservation, or delegation, and a
    mre>    timestamp of the last time the client held locking
    mre>    state.

If I understand your proposal, it seems like the server would have to
update the timestamp (and therefore, stable storage) fairly often.
I'm wondering if a less expensive approach is possible.  The Spritely
NFS papers talk about recording the "epoch" of the client's activity,
where each server reboot starts a new epoch.  This would presumably
reduce how often the server has to update stable storage.

    mre>    The third lock revocation event can occur as a result of
    mre>    administrative intervention within the lease period.
    mre>    While this is considered a rare event, it is possible that
    mre>    the server's administrator has decided to release or
    mre>    revoke a particular lock held by the client.  As a result
    mre>    of revocation, the client will receive an error of
    mre>    NFS4ERR_ADMIN_REVOKED and the error is received within the
    mre>    lease period for the lock.

I'm not sure that a new ADMIN_REVOKED error is necessary, but it does
seem cleaner, so I don't have a problem with it.

cheers,
mike

---

From: Mike Eisler <[email-masked]>
Date: Wed, 21 Aug 2002 17:16:21 -0700

> reduce how often the server has to update stable storage.

Yet another example as to why we have to be careful about implementation
suggestions. I agree that a more optimal approach is possible.

I wrote:

I think if the server simply recorded the fact that client established
a lock after a server incarnation, it would not be necessary for
the server to keep re-recording this information. That seems to be
equivalent to what you wrote regarding Spritely NFS epochs.

If we've reached consensus, I will send Spencer the corrected edits
today.

---

From: [email-masked]
Date: Sat, 24 Aug 2002 16:11:02 -0700

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

    mre> If we've reached consensus, I will send Spencer the corrected
    mre> edits today.

Just in case you're waiting for a response from me, I'm happy with the
results of our discussion.

mike