Subject: Re: [nfsv4] pnfs session issue

From: Mike Eisler <[email-masked]>
Date: Thu, 21 Feb 2008 16:15:57 -0800 (PST)

> 
> On Feb 21, 2008, at 1:09 PM, Mike Eisler wrote:
> 
> > +     server to cull an inactive session. If the interval between
> > +     two SEQUENCE operations each sent on different COMPOUND  
> > requests is less
> > +     than the lease_time attribute (<xref  
> > target="attrdef_lease_time" />),
> > +     then the session is considered active.
> 
> 
> 
> I have to see where this appears.. but this can not be strictly be
> true
> since we said the lease is valid for the entire COMPOUND...

OK, good point.

Newer diffs attached.

Index: nfsv41_middle_core_infrastructure.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_core_infrastructure.xml,v
retrieving revision 1.86
diff -u -w -b -r1.86 nfsv41_middle_core_infrastructure.xml
--- nfsv41_middle_core_infrastructure.xml	21 Feb 2008 12:58:17 -0000	1.86
+++ nfsv41_middle_core_infrastructure.xml	22 Feb 2008 00:04:03 -0000
@@ -3453,7 +3453,7 @@
    </t>
    </section> <!-- Obligations of the Server -->
 
-   <section anchor="Obligations of the Client" title="Obligations of the Client">
+   <section anchor="Obligations_of_the_Client" title="Obligations of the Client">
    <t>
    The client SHOULD honor the following obligations in order to
    utilize the session:
@@ -3464,7 +3464,11 @@
      sending operations risks having the session be destroyed
      by the server. This is because sessions consume
      resources, and resource limitations may force the
-     server to cull an inactive session.
+     server to cull an inactive session. A server MAY consider
+     a session to be inactive if the client has not used
+     the session before the session inactivity timer (<xref
+     target="session_inactive"/>) has expired.
+
    </t>
    <t>
      Destroy the session when not needed. If a client has
@@ -3562,6 +3566,26 @@
    </section> <!-- Steps the Client Takes To Establish a Session -->
   </section> <!-- Session Mechanics - Steady State -->
 
+  <section anchor="session_inactive" title="Session Inactivity Timer" >
+  <t>
+   The server MAY maintain an session inactivity timer for
+   each session.  If the session inactivity timer expires,
+   then the server MAY destroy the session. To avoid losing
+   a session due to inactivity, the client MUST renew
+   the session inactivity timer. The length of session
+   inactivity timer MUST NOT be less than the lease_time
+   attribute (<xref target="attrdef_lease_time"/>).
+   As with lease renewal (<xref target="lease_renewal"/>),
+   when the server receives a SEQUENCE operation,
+   it resets the session inactivity timer, and MUST NOT allow the
+   timer to expire while the rest of the operations in the
+   COMPOUND procedure's request are still executing. Once the
+   last operation has finished, the server MUST set the session
+   inactivity timer to expire no sooner that the sum of the
+   current time and the value of the lease_time attribute.
+  </t>
+
+  </section>
   <section anchor="Session Mechanics - Recovery" title="Session Mechanics - Recovery">

Index: nfsv41_middle_file_layout.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_file_layout.xml,v
retrieving revision 1.47
diff -u -w -b -r1.47 nfsv41_middle_file_layout.xml
--- nfsv41_middle_file_layout.xml	21 Feb 2008 12:58:17 -0000	1.47
+++ nfsv41_middle_file_layout.xml	22 Feb 2008 00:04:03 -0000
@@ -176,12 +176,49 @@
    Another scenario is for the metadata server and the
    storage device to be distinct from one client's point of
    view, and the roles reversed from another client's point
-   of view. For example, in the cluster file system model
-   a metadata server to one client, may be a data server to
+   of view. For example, in the cluster file system model,
+   a metadata server to one client may be a data server to
    another client. If NFSv4.1 is being used as the storage
    protocol, then pNFS servers need to encode the values
    of filehandles according to their specific roles.
   </t>
+  <section anchor="dsonly" title="Sessions Considerations for Data Servers">
+  <t>
+
+   <xref target="Obligations_of_the_Client" /> states
+   that a client has to keep its lease renewed in
+   order to prevent a session from being deleted by
+   the server. If the reply to EXCHANGE_ID has just the
+   EXCHGID4_FLAG_USE_PNFS_DS role set, then as noted in
+   <xref target="ds_ops"/> the client will not be able
+   to determine the data server's lease_time attribute,
+   because GETATTR will not be permitted. Instead, the
+   rule is that any time a client receives a layout
+   referring it to a data server that returns just
+   the EXCHGID4_FLAG_USE_PNFS_DS role, the client MAY
+   assume that the lease_time attribute from the metadata
+   server that returned the layout applies to the data
+   server. Thus the data server MUST be aware of the values
+   of all lease_time attributes of all metadata servers it
+   is providing I/O for, and MUST use the maximum of all such
+   lease_time values as the lease interval for all client
+   IDs and sessions established on it.
+
+  </t>
+  <t>
+
+   For example, if one metadata server has a lease_time
+   attribute of 20 seconds, and a second metadata
+   server has a lease_time attribute of 10 seconds,
+   then if both servers return layouts that refer to an
+   EXCHGID4_FLAG_USE_PNFS_DS-only data server, the data
+   server MUST renew a client's lease if the interval
+   between two SEQUENCE operations on different COMPOUND
+   requests is less than 20 seconds.
+
+  </t>
+ 
+  </section>
 
  </section>
 
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4

---

From: Robert Gordon <[email-masked]>
Date: Thu, 21 Feb 2008 19:21:30 -0600

> Newer diffs attached.

I like that, and i am happy :)

--
Robert
"Always do your best"