[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Re: lease period start / freeing of server state
From:       Eric Kustarz <Eric.Kustarz () eng ! sun ! com>
Date:       2001-09-21 21:15:37
Message-ID: 200109212122.f8LLMIVj920994 () jurassic ! eng ! sun ! com
[Download RAW message or body]


>Date: Fri, 21 Sep 2001 15:38:52 -0500
>From: Spencer Shepler <shepler@eng.sun.com>
>To: nfsv4-wg@sunroof.eng.sun.com
>Subject: lease period start / freeing of server state
>Mail-Followup-To: Spencer Shepler <shepler@eng.sun.com>, 
nfsv4-wg@sunroof.eng.sun.com
>Mime-Version: 1.0
>Content-Disposition: inline
>User-Agent: Mutt/1.3.19i
>
>On Fri, Sergey Klyushin wrote:
>>     > -----Original Message-----
>>     > From: Spencer Shepler [mailto:shepler@eng.sun.com]
>>     > Sent: Thursday, September 20, 2001 11:08 PM
>>     > To: nfsv4-wg@sunroof.eng.sun.com
>>     > Subject: Re: Issues list for RFC3010
>>     >
>>     >
>>     > On Thu, Sergey Klyushin wrote:
>>     > >     > > >SETCLIENTID_CONFIRM should also be added to the list for
>>     > >     > completeness.
>>     > >     > >
>>     > >     > > I don't agree with SETCLIENTID_CONFIRM.
>>     > >     > > 1. Until SETCLIENTID_CONFIRM is received there are either
>>     > >     > no established
>>     > >     > > states for the CLIENT, or all states will be
>>     > released on successful
>>     > >     > > SETCLIENTID_CONFIRM.
>>     > >     > > 2. If client was already confirmed,
>>     > SETCLIENTID_CONFIRM will be
>>     > >     > > retransmission or error from Server's point of view.
>>     > >     >
>>     > >     > So the larger issue is when does the server start the
>>     > countdown for
>>     > >     > the lease period.  Does the counter start when the
>>     > client instantiates
>>     > >     > its first state at the server via OPEN?  Is it from the
>>     > >     > SETCLIENTID_CONFIRM?
>>     > >     >
>>     > >     > I agree that SETCLIENTID_CONFIRM probably isn't
>>     > appropriate but we
>>     > >     > need to decide the meta issue to resolve this correctly.
>>     > >     >
>>     > >     > Spencer
>>     > >     >
>>     > > As far as I remember, RFC says that counter starts on
>>     > successful SETCLIENTID
>>     > > request. More than that,
>>     > > SETCLIENTID_CONFIRM should be send by client within lease period.
>>     >
>>     > I don't think there are comments in the RFC about the lease starting
>>     > at SETCLIENTID receipt.  If you find them, let me know. :-)
>>     >
>>     > In any case, if SETCLIENTID starts the lease period, then why wouldn't
>>     > SETCLIENTID_CONFIRM count towards renewal of that lease.
>>     >
>>     > We need to make it clear in the discussion of lease periods that if
>>     > the client is successful with a SETCLIENTID/SETCLIENTID_CONFIRM
>>     > sequence but does not send any other request within the lease period,
>>     > the client may (will more than likely) have to do the
>>     > SETCLIENTID/SETCLIENTID_CONFIRM sequence again before proceeding.
>>     >
>>     > This may be common.  For example, if a client is rebooted in the
>>     > middle of the night and mounts its filesystems from the server and in
>>     > doing so does the SETCLIENTID/SETCLIENTID_CONFIRM but has no further
>>     > activity it will probably not sit there and RENEW the lease at the
>>     > server.  To limit memory usage, the server will free the client's
>>     > references and the client will need to reestablish them.
>>     >
>>     > So I will add an item that the lease period start needs to be
>>     > clarified and a brief discussion of client recovery after no activity
>>     > (if it is not already covered).
>>     >
>>     > --
>>     >
>>     > - Spencer -
>>     >
>>     >
>> You are right, I was confused reading
>> =========================================================================
>> 8.1.2.  Server Release of Clientid
>>    If the server determines that the client holds no associated state
>>    for its clientid, the server may choose to release the clientid.  The
>>    server may make this choice for an inactive client so that resources
>>    are not consumed by those intermittently active clients.  If the
>>    client contacts the server after this release, the server must ensure
>>    the client receives the appropriate error so that it will use the
>>    SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity.
>>    It should be clear that the server must be very hesitant to release a
>>    clientid since the resulting work on the client to recover from such
>>    an event will be the same burden as if the server had failed and
>>    restarted.  Typically a server would not release a clientid unless
>>    there had been no activity from that client for many minutes.
>> =========================================================================
>> I translated "inactive client", "no activity from that client for many
>> minutes" to
>> no activity during lease period. Now I realized, that NFS Server should have
>> 4 timeouts
>> 1. Between SETCLIENTID and SETCLIENTID_CONFIRM.
>> 2. lease time for open_stateid
>> 3. lease time for locked_stateid
>> 4. Successful SETCLIENTID/SETCLIENTID_CONFIRM, but no activity from client,
>> meaning
>> no operations that allow Server find clientid (OPEN, LOCK, ...). The timeout
>> could be the same as for 1.
>> 
>> Am I wrong again?
>
>I don't think so but I think it might be helpful to state these
>differently.
>
>There is the ultimate timeout at the server -- the lease period.
>The questions here are: 
>	- when does the lease period start
>	- when does the lease period RENEWed (what operations)
>
>I would argue that the lease period starts when the first state
>operation (OPEN) is executed by the server for that client.  The lease
>is then renewed on the defined set of renewing operations.  By
>definition, if the lease period expires, the server is free to release
>all state and data structures related to that client.
>
>There are comments in the specification about the server's need to
>free data structures related to state that is not currently active.
>Things like a lockowner reference when that lockowner does not have
>any open files.  As has been pointed out, the clientid can also be
>freed at the server.  At a minimum, the server should wait for a full
>lease period before releasing the clientid (confirmed or not).  As for
>the lockowner references, I believe that we have discussed for the
>purposes of handling retransmitted CLOSEs that the server should wait
>a lease period before releasing that mechanism and therefore the
>server should probably wait a lease period before freeing the
>lockowner references.  I am not sure if this is too burdensome.
>
>For the case where the duration between SETCLIENTID_CONFIRM and OPEN
>is longer than a lease period, the server is allowed to free the
>clientid and return NFS4ERR_STALE_CLIENTID as a result of that OPEN.
>
>Does this need to be added to the document in a concise way?  Is this
>interpretation meet everyone's understanding?
>
>-- 
>
>- Spencer -

I agree but the wording needs to be changed a bit.  I think we need to 
differentiate between when the lease starts for the client and server.  The 
lease on the server technically starts at SETCLIENTID, is renewed at 
SETCLIENTID_CONFIRM, and is then further renewed by the normal means as stated 
in the spec (implicit and explicit renewals).

The lease on the client SHOULD start on its first state operation (OPEN with a 
valid clientid), but the client MAY start its lease before that (after a 
successful SETCLIENTID_CONFIRM).


eric




[prev in list] [next in list] [prev in thread] [next in thread]