Subject: [nfsv4] Open establishing new Lease Periods

From: Stevan Steve Allen <[email-masked]>
Date: Sat, 3 Apr 2004 10:37:25 -0800

I wish to verify the following conclusion.

RFC References:

14.2.34  "SETCLIENTID_CONFIRM does not establish or renew a lease." 

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.. It should be clear that the server must be very 
hesitant to release a clientid since the resulting work on the client....  
 Typically a server would not release a clientid unless there had been no 
activity from that client for many minutes." 

Conclusion:

  o   I did not find a mention in the RFC which ties "state" to clientid. 
        Mostly "state" is always in reference to opens or locks. 
  o   The clientid may be used to establish a new lease period 
        after the previous lease has timed out, except for next bullet
  o   If the prior lease has timed out AND held state has been release, 
        the server must fail the open with NFS4ERR_STALE_CLIENTID 
        and not establish a new lease period. 

The RFC verbiage above indicates a client does not need to renew a lease 
when "no associated state for its clientid" is held by the server.  e.g. 
RFC section 8.1.2 indicates when there is no state held for a clientid, 
the server may keep the clientid around for establishing new lease periods 
after a prior lease has expired. 

For a provided clientid, OPEN can establish or renew a lease period if 
   o  a lease period has yet to be established for this clientid
        (i.e. clients first OPEN)
   o  the lease for the clientid has not expired
   o  a lease period has not been established, or has expired, and 
        no prior state (share/lock) has been staled for this clientid

Thanks,
Stevan C. Allen

---

From: Stevan Steve Allen <[email-masked]>
Date: Sat, 3 Apr 2004 12:37:03 -0800

In addition to (and supersedes) my previous post...

The protocol allows a client which has released all state and let the 
lease expire, may start a new lease period (OPEN) under the same clientid 
(suggested by section 8.1.2 below).

Although the protocol indicates a client only needs to issue renew if the 
server holds state for a clientid (previous note).  The simpler process 
(and I suspect implemented by most) is that the client only initiates one 
lease period per clientid and will continually renew the lease (even if no 
state is held for the clientid by the server) until a stale or expired 
error is received, at which time the client will establish a new clientid 
using SETCLIENTID and _CONFIRM.   It may be simpler to state this is the 
only acceptable implementation.

otherwise.. RENEW may receive NFS4ERR_STALE_CLIENTID if the lease period 
has expired.  This error states a client must issue a new SETCLIENTID & 
CONFIRM.  The only way an second lease period may be started for a given 
clientid after the initial release has timed out is for the client not to 
issue a RENEW (or ignore the stale error) if there is no state held by the 
server for this clientid.  it's getting murky...

Thanks,
Stevan C. Allen

---- previous note ----

RFC References: 

8.1.2  Server Release of Clientid: "If the server determines that the 

Conclusion: 

        Mostly "state" is always in reference to opens or locks.
  o   After a lease has timed out,   the server may keep the clientid
        and start a new lease period under the existing clientid.
  o   The clientid may be used to establish a new lease period 
        after the previous lease has timed out, except for next bullet 
  o   If the prior lease has timed out AND held state has been release, 
        the server must fail the open with NFS4ERR_STALE_CLIENTID 
        and not establish a new lease period.   

Thanks,
Stevan C. Allen

---

From: Spencer Shepler <[email-masked]>
Date: Sat, 3 Apr 2004 15:33:46 -0600

Steve,

All state associated with a client is "rooted" by the clientid.  The 
reason for this is that
OPEN takes a clientid and returns stateids for the open file and 
optionally the
delegation for the file.  The first file lock, takes a stateid returned 
from OPEN and
returns a lock stateid, etc.

Note that RENEW uses a clientid to renew all state associated with that 
clientid
(all open files, file locks and delegations).

So there is a direct correlation between the clientid and all stateids.

The protocol allows a lot of flexibility for the server to hold state 
beyond the
defined lease period.  However, there is no minimum time that a 
clientid be
held active/valid after the SETCLIENTID_CONFIRM has been processed
successfully.  Most servers will hold the clientid for at least one 
lease period.

To state the obvious, once an active stateid is associated with the 
clientid,
the server must keep the state active for one lease period; the client 
is
required to renew that state within the lease period either explicitly 
with
RENEW or by the use of other state bearing operations.  Note that RENEW
must be used if the client has a callback path and holds delegations.
See NFS4ERR_CB_PATH_DOWN for the reason.

You mention the expected behavior by clients in the case that they hold
no state.  For the Solaris client, this is not true.  If there are no 
open files
or delegations held at a server, the client will cease to RENEW state
with that server.  To the client, the receipt of NFS4ERR_STALE_CLIENTID
and recovery from it is the same regardless of the cause of the 
condition.
The two most likely causes are network partition or no state held by the
client and RENEWs were not done.  The client will do the SETCLIENTID
dance and then check to see if file need to be reopened and so on.  If 
not,
then the original OPEN that started the whole thing will be retried.

If the above has missed a scenarios you are thinking of, please say so
and we can work through them.

Spencer

On Apr 3, 2004, at 2:37 PM, Stevan Steve Allen wrote:

> lease expire, may start a new lease period (OPEN) under the same 
> clientid (suggested by section 8.1.2 below).
>
> Although the protocol indicates a client only needs to issue renew if 
> the server holds state for a clientid (previous note).  The simpler 
> process (and I suspect implemented by most) is that the client only 
> initiates one lease period per clientid and will continually renew the 
> lease (even if no state is held for the clientid by the server) until 
> a stale or expired error is received, at which time the client will 
> establish a new clientid using SETCLIENTID and _CONFIRM.   It may be 
> simpler to state this is the only acceptable implementation.
>
> otherwise.. RENEW may receive NFS4ERR_STALE_CLIENTID if the lease 
> period has expired.  This error states a client must issue a new 
> SETCLIENTID & CONFIRM.  The only way an second lease period may be 
> started for a given clientid after the initial release has timed out 
> is for the client not to issue a RENEW (or ignore the stale error) if 
> there is no state held by the server for this clientid.  it's getting 
> murky...
>
> Thanks,
>  Stevan C. Allen
>
> ---- previous note ----
>
> client holds no associated state for its clientid, the server may 
> choose to release the clientid.. It should be clear that the server 
> must be very hesitant to release a clientid since the resulting work 
> on the client....    Typically a server would not release a clientid 
> unless there had been no activity from that client for many minutes." 
>  
>
>  Conclusion:
>
>  The RFC verbiage above indicates a client does not need to renew a 
> lease when "no associated state for its clientid" is held by the 
> server.  e.g. RFC section 8.1.2 indicates when there is no state held 
> for a clientid, the server may keep the clientid around for 
> establishing new lease periods after a prior lease has expired.  
>