From: Mike Eisler (mike@eisler.com)
Date: 08/21/02-07:16:21 PM Z
Message-ID: <3D642D55.8400C1D4@eisler.com> Date: Wed, 21 Aug 2002 17:16:21 -0700 From: Mike Eisler <mike@eisler.com> Subject: Re: Issue 05 was (lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt") mike.kupfer@sun.com wrote: > 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. 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: 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. 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. > > 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:16 AM Z CST