Subject: RE: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.t xt

From: Carl Burnett <[email-masked]>
Date: Fri, 9 Aug 2002 17:03:47 -0500

I looked at some of my old notes from a review of the 01-00 version of the 
draft. Oddly enough I have a comment almost identical yours below Dave. I 
came to the same conclusion that this issue is independent of holding the 
lock beyond the expiration. This is one I meant to discuss at the bake 
off, but forgot.

The other thought here is that if it is a requirement (MUST) for a server 
to record lease expiration in stable storage, then that adds reasonable 
burden to the server implementation. I would not want to let this keep me 
from getting an implementation out. Instead, I would implement my client 
to make extra checks when accepting a reclaimed lock. That is I would 
check that the file has not changed before considering the lock state 
recovered.

I am curious to know if the Linux, or other  implementations are currently 
logging such events to disk.

In the case where the server does know that a reclaim should not be 
granted, I assume it should return the error NFS4ERR_RECLAIM_CONFLICT.

Carl

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

"Noveck, Dave" <[email-masked]>
Sent by: [email-masked]
08/09/2002 02:46 PM

        To:     "[email-masked]'" <[email-masked]>, Mike Eisler 
<[email-masked]>
        cc:     [email-masked]
        Subject:        RE: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.t       xt

I just don't understand how that scenario depends at all on the
fact that you are allowing locks to be held beyond the expiration
of the lease.

Scenario 1a:

     Client gets lock
     Lease expires -- lock stays aorund
     one second later -- Conflicting lock request 
     original client loses lock
     second client does an unlock
     server reboot
     First client reclaims his lock
     Server erroneously grants reclaim -- unless info in stable storage
         prevents that

Scenario 1b:

     Client gets lock
     Lease expires -- lock release
     one second later -- Conflicting lock request 
     second client does an unlock
     server reboot
     First client reclaims his lock
     Server erroneously grants reclaim -- unless info in stable storage
         prevents that

In the second case, the information is more limited in that you just
have the fact that the client as a whole has lost his locks, and there
is no question of recording individual locks.  However, the spec says
that even in the keep-expired-locks-around case, the server may choose 
to only record the fact that the client as whole has lost at least one 
lock.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 09, 2002 2:57 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: questions and comments on
draft-ietf-nfsv4-rfc3010bis-02-03.txt 

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

    mre> Regarding,

    mre>    If the server continues to hold locks beyond the
    mre>    expiration of a client's lease, the server MUST employ a
    mre>    method of recording this fact in its stable storage.

    mre> I don't see what (though I vaguely recall understanding this
    mre> 3 years ago) holding the locks has to with the stable storage
    mre> requirement. Clarification is needed.

This is related to the scenario that appears a few more lines down in
the I-D.  The idea was to let the client recover its locks after a
network partition, as long as nobody else got a conflicting lock
during the partition.  The stable storage part comes in because the
server has to safely remember whether it granted any conflicting
locks.

mike