Subject: RE: file_id

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 5 Dec 2002 06:52:27 -0800

When you say,

> So if the server restarts and finds a lease in effect,

You are assuming that the server knows if there are leases in
effect, presumably through recording this information on stable
storage.  While the spec allows such an implementation (and
there are lots of reasons that it would be desirable to do),
it also allows the approach of the server coming up and not 
knowing anything, establishing a fixed length grace period
and waiting for the clients to reclaim their locks, if any.

During this period, if the client did have a file open
before the reboot, the client continues to have a file open,
from it's own point of view.  When the client discovers a
reboot has occurred, then it knows that although the file
is open from its own point of view, it knows that the 
server doesn't agree, and so it does an open-reclaim to
rectify that, at which point the server and the client 
agree that the file is open and (has been open all the 
intervening time :-).  In particular, the client has 
a guarantee that no conflicting open was granted while,
it had the file open, including during the grace period.

During the grace period, the server needs to deflect any
requests that cannot be granted because they might conflict
with an open file of which the server is unaware.  He 
can't reject them absolutely (by an error that indicates 
there is a conflicting open) because such an agnostic server
will not know if the opens exist or not.  This leads to ugly
long request re-issue cycles, as you note.  That's why it is
desirable to save information that allows the server to make the
determination without waiting for the grace period to expire.
This may take the form of summary information that allows 
large numbers of cases to be resolved even if some requests
may have to wait for resolution.  Making the problem smaller
may be better than waiting until it can be solved entirely.

Confession: Our server currently doesn't record lease information
on stable storage and uses the simple dumb strategy discussed 
above. 

-----Original Message-----
From: Talpey, Thomas [mailto:[email-masked]]
Sent: Wednesday, December 04, 2002 9:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: file_id

Okay, so we do disagree on what the grace period means.

I assert the file is open during the grace period. Server failure
doesn't affect the client's open state. Only server failure *plus*
grace period changes that, and grace periods can be long.

Tom.

At 09:40 PM 12/4/2002, Spencer Shepler wrote:
>On Wed, Talpey, Thomas wrote:
>> I believe I have the same picture of grace periods as you. But
>> I view the grace period as favoring the client, not the server.
>> So if the server restarts and finds a lease in effect, the grace
>> period is there to hold that guarantee to the client. The client
>> may take a while to come back and reclaim, but by no means
>> is this a reason for the server to start telling other clients to
>> sharpen their knives.
>> 
>> Put it this way. Choosing NFS4ERR_FILE_OPEN versus
>> NFS4ERR_GRACE versus NFS4ERR_DELAY in no way
>> changes the effect on the file in question. And the latter two
>> introduce a new client behavior if they encourage a retransmit
>> cycle, of possibly very long duration. Why do this?
>
>The server has to respond with something.  NFS4ERR_FILE_OPEN is
>inappropriate because that says:
>
>   NFS4ERR_FILE_OPEN     The operation can not be successfully processed
>                         because a file involved in the operation is
>                         currently open.
>
>and if the client doing the RENAME/REMOVE were to receive this it
>would return an error to the caller/application.  The other reason the
>server can not return this error is that it doesn't know (in the case
>that Mike stated) if the file will be OPENed/reclaim during the grace
>period.  
>
>So that leaves NFS4ERR_GRACE or NFS4ERR_DELAY.  The client is free to
>set its own timeouts for retransmitting its request for those
>operations.  I don't see a problem with that.  The client request will
>be resolved at the end of the server's grace period.
>
>Spencer