Re: lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt")

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Benny Halevy (benny_halevy@yahoo.com)
Date: 08/13/02-11:44:55 AM Z


Message-ID: <20020813164455.84719.qmail@web14108.mail.yahoo.com>
Date: Tue, 13 Aug 2002 09:44:55 -0700 (PDT)
From: Benny Halevy <benny_halevy@yahoo.com>
Subject: Re: lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt")

--- Carl Burnett &lt;cburnett@us.ibm.com&gt; wrote:
&gt; I think the client implementation can guard against corruption.
When
&gt; a 
&gt; client recovers a lock after a server reboot, it can further check
&gt; that 
&gt; the file's data has not changed (time_modify). If it has, then the
&gt; client 
&gt; does not consider the locking state recovered.

It wouldn't be very useful when there are multiple writers, each
writing to a _disjoint_ byte range of the file. In that case
time_modify (or even better - the change attribute) will rightfully
change regardless of locking, leases, and lease expiration.

&gt; 
&gt; It is of course a good feature for the server to persistently
track
&gt; state 
&gt; expiration in order to deny invalid renew requests, but I am not
sure
&gt; the 
&gt; protocol should dictate this in the implementation.
&gt; 
&gt; Carl
&gt; 
&gt; 
&gt; Carl Burnett
&gt; AIX Kernel Architecture - Distributed File Systems
&gt; (512) 838-8498, TL 678-8498
&gt; (please reply to cburnett@us.ibm.com)
&gt; 
&gt; 
&gt; 
&gt; 
&gt; 
&gt; mike.kupfer@sun.com
&gt; Sent by: owner-nfsv4-wg@sunroof.eng.sun.com
&gt; 08/12/2002 03:16 PM
&gt; 
&gt;  
&gt;         To:     mike@eisler.com
&gt;         cc:     nfsv4-wg@sunroof.eng.sun.com
&gt;         Subject:        lease expiration, stable storage (was
&gt; &#34;questions/comments on 
&gt; draft-ietf-nfsv4-rfc3010bis-02-04.txt&#34;)
&gt; 
&gt;  
&gt; 
&gt; &gt;&gt;&gt;&gt;&gt; &#34;mre&#34; == Mike Eisler
&lt;mike@eisler.com&gt; writes:
&gt; 
&gt;     mre&gt; Regarding,
&gt; 
&gt;     mre&gt;    There are various
&gt;     mre&gt;    scenarios involving server failure after such an
event
&gt;     mre&gt;    that require the storage of these lease expirations
or
&gt;     mre&gt;    network partitions.  One scenario is as follows:
&gt; 
&gt;     mre&gt; Do we really want to require servers to do this?
&gt; 
&gt; Given the email exchange I just had with Dave Noveck (which should
be
&gt; in the WG mail archive), I don't see that we have any choice. 
Unless
&gt; the server records lease expirations in stable storage, we open up
a
&gt; window which can lead to file corruption.
&gt; 
&gt; mike
&gt; 
&gt; 
&gt; 


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:13 AM Z CST