Subject: Re: [nfsv4] Stateid Use for I/O Operations

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 18 Mar 2008 17:39:31 -0400

> I'll draft something and once we have something concrete 
> we'll see if we have a consensus to put it in. 

So the following are my suggested xml diffs in the form of a cvs diff
-c.  Comments appreciated.

Index: nfsv41_middle_state_mgmt.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_state_mgmt.xml,v
retrieving revision 1.29
diff -c -r1.29 nfsv41_middle_state_mgmt.xml
*** nfsv41_middle_state_mgmt.xml	25 Feb 2008 20:51:37 -0000
1.29
--- nfsv41_middle_state_mgmt.xml	18 Mar 2008 21:30:58 -0000
***************
*** 529,538 ****
        </section> <!-- "Stateid Lifetime and Validation" -->
        <section anchor="stateid_use" title="Stateid Use for I/O
Operations">
          <t>
!           Clients performing I/O operations (and SETATTR's modifying
the 
!           file size), need to select an appropriate stateid based on
the
            locks (including opens and delegations) held by the client
and 
            the various types of state-owners issuing the I/O requests.
          </t>
          <t>
            The following rules, applied in order of decreasing
priority, 
--- 529,540 ----
        </section> <!-- "Stateid Lifetime and Validation" -->
        <section anchor="stateid_use" title="Stateid Use for I/O
Operations">
          <t>
!           Clients performing I/O operations need to select an 
!           appropriate stateid based on the
            locks (including opens and delegations) held by the client
and 
            the various types of state-owners issuing the I/O requests.
+           SETATTR operations which change the file size are treated
+           like I/O operations in this regard.
          </t>
          <t>
            The following rules, applied in order of decreasing
priority, 
***************
*** 542,567 ****
            used.  (See <xref target="global_stateid" />).
            <list style='symbols'>
              <t>
!               If the client holds a delegation for the file in
question, the
!               delegation stateid should be used.
              </t>
              <t>
                Otherwise, if the lock-owner corresponding entity (e.g.
process)
                issuing the I/O has a lock stateid for the associated
open file,
!               then the lock stateid for that lock-owner and open file
should 
                be used.
              </t>
              <t>
                If there is no lock stateid, then the open stateid for
the open
!               file in question is used.
              </t>
              <t>
                Finally, if none of the above apply, then a special
stateid 
!               should be used.
              </t>
            </list> 
!         </t>   
        </section> <!-- "Stateid Use for I/O Operations" -->
      </section> <!-- "Stateid Definition" -->
    <section anchor="lease_renewal" title="Lease Renewal" >
      <t>
--- 544,603 ----
            used.  (See <xref target="global_stateid" />).
            <list style='symbols'>
              <t>
!               If the client holds a delegation for the file in
question, 
!               the delegation stateid SHOULD be used.
              </t>
              <t>
                Otherwise, if the lock-owner corresponding entity (e.g.
process)
                issuing the I/O has a lock stateid for the associated
open file,
!               then the lock stateid for that lock-owner and open file
SHOULD 
                be used.
              </t>
              <t>
                If there is no lock stateid, then the open stateid for
the open
!               file in question SHOULD be used.
              </t>
              <t>
                Finally, if none of the above apply, then a special
stateid 
!               SHOULD be used.
              </t>
            </list> 
!         </t> 
!         <t>
!           Ignoring these rules may result in situations in which the
server
!           does not have information necessary to properly process the
request.
!           For example, when mandatory byte-range locks are in effect,
if the
!           stateid does not indicate the proper lockowner, via a lock
stateid,
!           a request might be avoidably rejected.
!         </t>
!         <t>
!           The server however should not try to enforce these ordering
rules 
!           and should use whatever information is available to proper
process 
!           I/O requests.
!           In particular, when a client has a delegation for a given
file, it
!           SHOULD take note of this fact in processing a request, even
if it is
!           sent with a special stateid.
!         </t>  
        </section> <!-- "Stateid Use for I/O Operations" -->
+       <section anchor="stateid_use_sa" title="Stateid Use for SETATTR
Operations">
+         <t>
+           Because each operation is associated with a sessionid and
from that
+           the clientid can be determined, operations do not need to 
+           include a stateid for the server to be able to determine
whether the 
+           they should cause a delegation to be recalled or are to be 
+           treated as done within the scope of the delegation.
+         </t>
+         <t>
+           In the case of SETATTR operations, a stateid is present.  In
cases
+           other than those which set the file size, the client may
send either
+           a special stateid or, when a delegation is held for the file
in 
+           question, a delegation stateid.  While the server SHOULD
validate
+           the stateid and may use the stateid to optimize the
determination
+           as to whether a delegation is held, it SHOULD note the
presence of
+           a delegation even when a special stateid is sent, and MUST
accept a
+           valid delegation stateid when sent.
+         </t>
+       </section> <!-- "Stateid Use for SETATTR Operations" -->
      </section> <!-- "Stateid Definition" -->
    <section anchor="lease_renewal" title="Lease Renewal" >
      <t>

-----Original Message-----
From: Noveck, Dave 
Sent: Friday, March 14, 2008 6:41 PM
To: 'Trond Myklebust'
Cc: Mike Eisler; [email-masked]
Subject: RE: [nfsv4] Stateid Use for I/O Operations

> I'd certainly vote for such a text. 

Spencer will explain to you that we don't vote.

If that changes, you'll get a by-mail do-over ballot :-)

> AFAICS this client behaviour is necessary in the NFSv4.0 case (and 
> hopefully will be part of any errata and/or best practices text that 
> we end up producing), whereas it can't hurt in the v4.1 case...

I'll draft something and once we have something concrete we'll see if we
have a consensus to put it in.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Friday, March 14, 2008 6:20 PM
To: Noveck, Dave
Cc: Mike Eisler; [email-masked]
Subject: RE: [nfsv4] Stateid Use for I/O Operations

On Fri, 2008-03-14 at 17:43 -0400, Noveck, Dave wrote:
> > Yes, but I can see a good case for wanting to minimise the changes 
> > between v4.0 and v4.1 if we don't really care.
> 
> > In particular, I don't think we want to have v4.1 servers 
> > deliberately censoring clients that do supply the delegation in the 
> > case of mtime/acl/... changes.
> 
> I agree with that.
> 
> Any time a client MAY send a special stateid and if the client holds a

> delegation, it also MAY send the stateid for that delegation and the 
> server MUST accept it.  If we have agreement on that, then I can draft

> the appropriate text.
> 
> Given what is there now, I would not expect servers to reject this, 
> but I can see laying this out explicitly.

I'd certainly vote for such a text. AFAICS this client behaviour is
necessary in the NFSv4.0 case (and hopefully will be part of any errata
and/or best practices text that we end up producing), whereas it can't
hurt in the v4.1 case...

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 18 Mar 2008 19:36:05 -0400

Just a single comment/query about the use of the word 'SHOULD' here (See
the inlined note). Otherwise, I'm happy.

Cheers
  Trond

> Index: nfsv41_middle_state_mgmt.xml

Just a technical question about the use of 'SHOULD': in certain cases
(e.g. WANT_DELEGATION), the server may believe that the client is
holding a delegation, whereas the client may not yet have
received/processed the RPC call that issued it. Is the use of 'SHOULD'
here compatible with this race?

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 18 Mar 2008 21:26:44 -0400

I would argue that since SHOULD means that if there is some good
technical reason you can't do the specified action, you are OK.  Not
having received the message that tells you have the delegation seems
like a good reason to me.

However, to resolve all doubt I propose modifying the second paragraph
in the section to read as follows:

   The following rules, applied in order of decreasing priority, 
   govern the selection of the appropriate stateid.  In following 
   these rules, the client will only consider locks of which it
   has actually received notification by an appropriate operation
   response or callback.  Note that the
   rules are slightly different in the case of I/O to data servers
   when file layouts are being 
   used.  (See <xref target="global_stateid" />).  

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 7:36 PM
To: Noveck, Dave
Cc: Mike Eisler; [email-masked]
Subject: RE: [nfsv4] Stateid Use for I/O Operations

Cheers
  Trond

On Tue, 2008-03-18 at 17:39 -0400, Noveck, Dave wrote:
> > I'll draft something and once we have something concrete we'll see 
> > if we have a consensus to put it in.
> 

> +       <section anchor="stateid_use_sa" title="Stateid Use for 
> + SETATTR
> Operations">
> +         <t>

> +           In the case of SETATTR operations, a stateid is present.  
> + In
> cases
> +           a special stateid or, when a delegation is held for the 
> + file
> in

> I'll draft something and once we have something concrete we'll see if 
> we have a consensus to put it in.
> 

> > > deliberately censoring clients that do supply the delegation in 
> > > the case of mtime/acl/... changes.
> > 
> > I agree with that.
> > 
> > Any time a client MAY send a special stateid and if the client holds

> > a

> necessary in the NFSv4.0 case (and hopefully will be part of any 
> errata and/or best practices text that we end up producing), whereas 
> it can't hurt in the v4.1 case...
>

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 21 Mar 2008 15:52:56 -0400

It looks like we have a rough consensus for this and I'll check it in
tonight.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 7:36 PM
To: Noveck, Dave
Cc: Mike Eisler; [email-masked]
Subject: RE: [nfsv4] Stateid Use for I/O Operations

Cheers
  Trond