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

From: "Mike Eisler" <[email-masked]>
Date: Fri, 14 Mar 2008 10:56:56 -0700 (PDT)

The section
  Stateid Use for I/O Operations
has this list:

   The following rules, applied in order of decreasing priority, govern
   the selection of the appropriate stateid.  Note that the rules are
   slightly different in the case of I/O to data servers when file
   layouts are being used.  (See Section 13.9.1).

   o  If the client holds a delegation for the file in question, the
      delegation stateid should be used.

   o  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.

   o  If there is no lock stateid, then the open stateid for the open
      file in question is used.

   o  Finally, if none of the above apply, then a special stateid should
      be used.

------------------

I'm wondering if the "should"s ought to be "SHOULD"s.

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Mar 2008 16:41:12 -0400

>    o  Finally, if none of the above apply, then a special stateid should

I have a question about that section. It appears to imply that in the
case of SETATTR you only need to use the stateid in the case of a change
of file size.

Question: What about a change of mtime/mode/owner/acl/...?

If you have a write delegation, you should be able to change those
attributes without causing a delegation recall. Does the server have
sufficient information from the SEQUENCE op (clientid+sessionid) to
deduce that it does not have to recall the delegation, or does the
client need to supply the delegation stateid for this case too?

...and if the SEQUENCE op really contains enough information to deduce
that the client holds a delegation, then why do we need to supply a
delegation stateid for the case of a SETATTR that changes the file size?

Cheers
  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Mar 2008 17:14:39 -0400

> If you have a write delegation, you should be able to change 
> those attributes without causing a delegation recall. Does the 
> server have sufficient information from the SEQUENCE op 
> (clientid+sessionid) to deduce that it does not have to 
> recall the delegation, or does the client need to supply 
> the delegation stateid for this case too?

It has enough information from the sessionid since this allows it go
from that to the clientid.

> ...and if the SEQUENCE op really contains enough information 
> to deduce that the client holds a delegation, then why do we 
> need to supply a delegation stateid for the case of a SETATTR 
> that changes the file size? 

No but it seemed simplest and best to treat SETATTR which changed file
size like another IO operation (another sort of WRITE).  For example,
you might have mandatory byte range locks that would prevent you from
modifying a range and in this case you would need to know if the issuer
was lockowner allowed to make the change via SETATTR.  Given that, it
made most sense to have one set of rules for all IO and IO-like
operations rather than try to eliminate individual sub-cases where we
might be able to do without a particular stateid.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Friday, March 14, 2008 4:41 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] Stateid Use for I/O Operations

Cheers
  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Mar 2008 17:20:52 -0400

I think "SHOULD" is reasonable for this. 

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Friday, March 14, 2008 1:57 PM
To: [email-masked]
Subject: [nfsv4] Stateid Use for I/O Operations

The section

------------------

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Mar 2008 17:26:08 -0400

> might be able to do without a particular stateid.

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.

Cheers
  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Mar 2008 17:43:57 -0400

> 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.  

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

> > sufficient information from the SEQUENCE op
> > (clientid+sessionid) to deduce that it does not have to recall the 
> > delegation, or does the client need to supply the delegation stateid

> > for this case too?
> > ...and if the SEQUENCE op really contains enough information to 
> > deduce that the client holds a delegation, then why do we need to 
> > supply a delegation stateid for the case of a SETATTR that changes 
> > the file size?
> 

> modifying a range and in this case you would need to know if the 
> issuer was lockowner allowed to make the change via SETATTR.  Given 
> that, it made most sense to have one set of rules for all IO and 
> IO-like operations rather than try to eliminate individual sub-cases 
> where we might be able to do without a particular stateid.

Cheers
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Mar 2008 18:20:06 -0400

> 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...

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Mar 2008 18:41:24 -0400

> 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:
> > deliberately censoring clients that do supply the delegation in the 
> > case of mtime/acl/... changes.
> 
> I agree with that.
> 

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