Subject: [nfsv4] [NFSv4.2] Meeting Minutes for 8/25/11 (UPDATED Conference Call ID: 4082151519)

From: Thomas Haynes <[email-masked]>
Date: Thu, 25 Aug 2011 22:35:23 -0500

Attendees
--------------

- Spencer Shepler (Microsoft)
- Rob Thurlow (Oracle)
- Chuck Lever (Oracle)
- Dean Hildebrand (IBM)
- Trond Myklebust (NetApp)
- Mike Eisler (NetApp)
- Peter Staubach (EMC)
- Jarrett Lu (Oracle)
- Manjunath Shankararao (NetApp)
- Tom Haynes (NetApp)

+ IETF Note Well Agreement

   http://www.ietf.org/NOTEWELL.html

+ Status on the IO_ADVISE I-D to integrate into NFSv4.2

Open Discussion
- multi byte range support
- Trond points out two cases for multiple ranges
 - read-ahead for a very large file - would like to specify a byte
   range instead of the entire file
 - other case is the DONTWANT (opposite of caching), specifying the
   range to allow for cache release of portion of file
- Summary is that current posix hinting is "stateless" - action is taken
 and that is it
**- Confusion about two hints with different ranges and there effects
- madvise() is another interface that allows for this

Converged on the following
- stateful hint
- ephemeral hint

Dean will push out the current I-D as is and discuss and 
modify from there.

+ Trond brought up AUTH_NULL for 3530bis. Tom stated that he was
going to host a "Last Call" Call next week to close things out by going over
the remaining comments. This also includes the recent discussion about
what OPEN returns when a non-regular file is attempted to be opened.

So, please summarize any open issues you have on 3530bis on the
mailing list and provide any text suggestions you have. We will finalize
whether we take changes in the meeting.

And a great big thanks to Spencer for taking the notes, etc.

---

From: Spencer <[email-masked]>
Date: Thu, 25 Aug 2011 20:57:28 -0700

On Aug 25, 2011, at 8:35 PM, Thomas Haynes wrote:

> Tom stated that he was

This is an excellent idea.  As Tom suggests, please post to the WG
alias and anything left unresolved will be discussed during the concall.

Thanks,
Spencer

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 26 Aug 2011 12:56:15 -0400

> alias and anything left unresolved will be discussed during the concall.

The two issues on my list are:

     1. What does it mean when I find AUTH_NULL listed as a flavour in
        the SECINFO results? Historically in the NFSv3 MOUNT protocol,
        Solaris and other server vendors have apparently used AUTH_NULL
        as a 'wildcard flavour'. IOW: any authentication flavour which
        is not explicitly listed elsewhere may still be used by the
        client, but the server will treat the resulting RPC call as if
        it were authenticated using AUTH_NULL (which usually means that
        the user/group id will be squashed to the anonymous user). 
     2. What error value should the server return when an OPEN request
        is attempted on an object which is not a regular file, directory
        or symlink. The current practice that many servers observe of
        returning NFS4ERR_INVAL is in direct conflict with the
        definition that this means 'Invalid argument or unsupported
        argument for an operation.'. The client is supplying a directory
        filehandle and a filename - both of which can trigger an
        NFS4ERR_INVAL. It isn't supplying a file as an argument, so
        where does the justification for NFS4ERR_INVAL come from?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 26 Aug 2011 18:01:10 +0000

Thanks for pushing posting these.

Here is my brief take on the two issues.

SECINFO (AUTH_NULL):  With the current definition in NFSv4, SECINFO is
providing the list of authentication types that are valid for that
portion of the namespace.  There is no other implied behaviors as has
been implemented for NFSv3/MOUNT.

Having said that, if someone would like to write an I-D describing this
additional behavior, that would be fine with me.  This I-D could move 
forward as a separate I-D/RFC on the standards track and apply to NFSv4
in general.

For the error on OPEN of a non-file.  The bis document does indicate
NFS4ERR_ISDIR and NFS4ERR_SYMLINK as valid errors for OPEN.  Looks
as though the server implementations should be changed to return
those errors as more appropriate for the type of failure.

Do we need additional text in the bis to make it clear?  Seems
like a slippery slope that we have to update the RFC
to add a MUST for every error return.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Trond Myklebust
> Sent: Friday, August 26, 2011 9:56 AM
> To: Spencer
> Cc: nfsv4 nfsv4
> Subject: Re: [nfsv4] [NFSv4.2] Meeting Minutes for 8/25/11 (UPDATED
> Conference Call ID: 4082151519)
> 
> > > going to host a "Last Call" Call next week to close things out by
> > > going over the remaining comments. This also includes the recent
> > > discussion about what OPEN returns when a non-regular file is
> attempted to be opened.
> > >
> > > mailing list and provide any text suggestions you have. We will
> > > finalize whether we take changes in the meeting.
> >
> >
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Rick Macklem <[email-masked]>
Date: Fri, 26 Aug 2011 14:21:45 -0400 (EDT)

> those errors as more appropriate for the type of failure.
Wasn't Trond arguing that NFS4ERR_SYMLINK be returned for Opens of all
non-regular files? (I just patched the FreeBSD server to do that, including
the NFDIR case.)

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 26 Aug 2011 18:55:07 +0000

> From: Rick Macklem [mailto:[email-masked]]
> Sent: Friday, August 26, 2011 11:22 AM
> To: Spencer Shepler
> Cc: nfsv4 nfsv4; Trond Myklebust; Spencer
> > Having said that, if someone would like to write an I-D describing
> > this additional behavior, that would be fine with me. This I-D could
> > move forward as a separate I-D/RFC on the standards track and apply to
> > NFSv4
> > in general.
> >
> >
> > NFS4ERR_ISDIR and NFS4ERR_SYMLINK as valid errors for OPEN. Looks as
> > though the server implementations should be changed to return those
> > errors as more appropriate for the type of failure.
> >
> non-regular files? (I just patched the FreeBSD server to do that,
> including the NFDIR case.)
> 

Seems appropriate that the server return ISDIR when it is a directory
and SYMLINK when it is a symlink.  Don't need to fold everything 
into SYMLINK.

Spencer

> > Do we need additional text in the bis to make it clear? Seems like a
> > slippery slope that we have to update the RFC to add a MUST for every
> > error return.
> >
> > Spencer
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Trond Myklebust
> > > > > going to host a "Last Call" Call next week to close things out
> > > > > by going over the remaining comments. This also includes the
> > > > > recent discussion about what OPEN returns when a non-regular
> > > > > file is
> > > attempted to be opened.
> > > > >

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 26 Aug 2011 14:58:48 -0400

On Fri, Aug 26, 2011 at 06:01:10PM +0000, Spencer Shepler wrote:
> Do we need additional text in the bis to make it clear?

Yes, please.  The Linux client expects SYMLINK for opens of device
special files.  The only two server implementations we've heard about
(Linux and Freebsd) do something else.

It's frustrating not to have heard anything about other implementations,
but as it is we have enough evidence of an interoperability problem.

Here's a stab at text if we agree this is the correct solution.  I'd be
fine with dropping the final sentence if we think the extra explanation
is overkill.

--b.

commit 1c4979d54078af7bcc1be70b122c85422b38cb25
Author: J. Bruce Fields <[email-masked]>
Date:   Fri Aug 26 14:55:45 2011 -0400

    OPEN: return NFS4ERR_SYMLINK for non-regular files

diff --git a/nfsv4_middle_procedures.xml b/nfsv4_middle_procedures.xml
index bdb0a74..3cc6094 100644
--- a/nfsv4_middle_procedures.xml
+++ b/nfsv4_middle_procedures.xml
@@ -2103,8 +2103,17 @@
       </t>
 
       <t>
-        If the component provided to OPEN is a symbolic link,
-        the error NFS4ERR_SYMLINK will be returned to the client.
+        If the component provided to the OPEN resolves to something
+        other than a regular file, an error will be returned to the
+        client.  If it is a directory, NFS4ERR_ISDIR is returned;
+        otherwise, NFS4ERR_SYMLINK is returned.  Note that
+        NFS4ERR_SYMLINK is returned for both symlinks and for special
+        files of other types; NFS4ERR_INVAL would be inappropriate,
+        since the arguments provided by the client were correct, and
+        the client cannot necessarily know at the time it sent the OPEN
+        that the component would resolve to a non-regular file.
+
+      <t>
         If the current filehandle is not a directory, the error
         NFS4ERR_NOTDIR will be returned.
       </t>

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 26 Aug 2011 15:08:42 -0400

> and SYMLINK when it is a symlink.  Don't need to fold everything 

Right, but the question is what to return when the object turns out to
be a fifo, block device, character device or socket. Either ISDIR and
SYMLINK would be fine with me.

NetApp

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 26 Aug 2011 15:15:00 -0400

Also, a less controversial change, noted while looking at error returns.

--b.

diff --git a/nfsv4_middle_procedures.xml b/nfsv4_middle_procedures.xml
index 3cc6094..98c45a7 100644
--- a/nfsv4_middle_procedures.xml
+++ b/nfsv4_middle_procedures.xml
@@ -2666,7 +2666,7 @@
       <t>
         If the current filehandle is not a regular file, an error
         will be returned to the client.  In the case the current
-        filehandle represents a directory, NFS4ERR_ISDIR is return;
+        filehandle represents a directory, NFS4ERR_ISDIR is returned;
         otherwise, NFS4ERR_INVAL is returned.
       </t>

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 31 Aug 2011 15:04:04 -0700

> +++ b/nfsv4_middle_procedures.xml

Does anyone have any object to this text?

If I don't hear any objection back, I'm going to pull this change from Bruce and
mark the AI closed.

I think Rick mentioned he was changing FreeBSD to match this...