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

From: Carl Burnett <[email-masked]>
Date: Tue, 13 Aug 2002 08:04:00 -0500

I think the client implementation can guard against corruption. When a 
client recovers a lock after a server reboot, it can further check that 
the file's data has not changed (time_modify). If it has, then the client 
does not consider the locking state recovered.

It is of course a good feature for the server to persistently track state 
expiration in order to deny invalid renew requests, but I am not sure the 
protocol should dictate this in the implementation.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

[email-masked]
Sent by: [email-masked]
08/12/2002 03:16 PM

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        lease expiration, stable storage (was "questions/comments on 
draft-ietf-nfsv4-rfc3010bis-02-04.txt")

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

    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: Benny Halevy <[email-masked]>
Date: Tue, 13 Aug 2002 09:44:55 -0700 (PDT)

--- Carl Burnett &lt;[email-masked]&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 [email-masked])
&gt; 
&gt; 
&gt; 
&gt; 
&gt; 
&gt; [email-masked]
&gt; Sent by: [email-masked]
&gt; 08/12/2002 03:16 PM
&gt; 
&gt;  
&gt;         To:     [email-masked]
&gt;         cc:     [email-masked]
&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;[email-masked]&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