Adamson, Andy | 28 Jul 19:21 2014


Hi Spencer

I’m requesting that we move this from a personal draft to an NFSv4 WG draft.


nfsv4 mailing list
nfsv4 <at>

Matt W. Benjamin | 25 Jul 17:45 2014

update pnfs metastripe draft

As noted in the WG meeting, we've updated the current pNFS metastripe

IETF tools confirmation:

A new version of I-D, draft-mbenjamin-nfsv4-pnfs-metastripe-03.txt
has been successfully submitted by Matt Benjamin and posted to the
IETF repository.

Name:                draft-mbenjamin-nfsv4-pnfs-metastripe
Revision:        03
Title:                pNFS Metadata Striping
Document date:        2014-07-24
Group:                Individual Submission
Pages:                23

   This Internet-Draft describes a means to add metadata striping to
   pNFS.  The text of this draft is substantially based on prior drafts
   by Eisler, M., with some departures.  The current draft attempts to
   define a somewhat lighter-weight protocol, in particular, seeks to
   permit striping for "filehandle only" operations such as LOCK and
   OPEN + CLAIM_FH, without clients having to obtain metadata layouts on
   regular files.  We gratefully acknowledge the primary contributions
   of Mike Eisler, Pranoop Ersani, and others.

(Continue reading)

Benjamin Kaduk | 25 Jul 16:01 2014

RPCSEC_GSSv3 and muti-principal authentication

Since we were having trouble channeling jabber into the meeting, let me 
try to say something using more words, here.

Andy had mentioned looking at the AFS "CombineTokens" operation from 
draft-wilkinson-afs3-rxgk-11 (which is great; trying to find prior art and 
not replicate other peoples' mistakes and all).  However, that document is 
something of a skeleton for how to use rxgk (i.e., not necessarily for 
AFS).  The actual concrete bits for using rxgk with AFS in particular, are 
in draft-wilkinson-afs3-rxgk-afs.  In particular, the plain 
"CombineTokens" operation is not currently very useful for AFS.  Instead, 
we define a similar operation, "AFSCombineTokens", which does the same 
sort of key mixing, but has a different behavior with repsect to 
identities.  This new AFSCombineTokens operation explicitly has a 
separation between "the user's identity" and "the identity of the 
machine/client acting on behalf of the user".  This lets the user's 
identity be used for filesystem access checks while avoiding the cache 
poisoning attacks that would be possible if just the user's credential was 
used directly.

I'm not sure that any of this is directly relevant for RPCSEC_GSSv3; I 
just wanted to point out that if Adam is looking for prior art, the 
problem AFSCombineTokens is trying to solve is closer to the problem that 
RPCSEC_GSS multi-principal authentication is trying to solve than the 
plain rxgk CombineTokens is.

Hopefully that makes sense.


(Continue reading)

Brian Pawlowski | 25 Jul 15:12 2014

The stream is now live

We noted well and genda bashed.

- Spencer expects to push the bis document up today.

- Tom Haynes is presenting NFS V4.2.

nfsv4 mailing list
nfsv4 <at>

Brian Pawlowski | 25 Jul 15:10 2014

Trying to get the stream working!

Jabber seems live.


nfsv4 mailing list
nfsv4 <at>

Brian Reitz | 24 Jul 18:23 2014

draft-bhalevy-nfsv4-flex-files-03 review comments

A simple typo from Section 1.1.  Definitions
Layout Type: describes both the storage protocol used to access the data and the aggregation scheme used to lays out the file data on the underlying storage devices.
Should be: “used to layout the file data….”
nfsv4 mailing list
nfsv4 <at>
Brian Reitz | 23 Jul 21:00 2014

draft-adamson-nfsv4-multi-domain-federated-fs-reqs-04 review comments

1)  In section 4.1:

      The name portion of name <at> domain MUST be unique within the
      specified NFSv4 domain.

Is this really a unique/new requirement of multi-domain FedFS?  Seems like this really is a requirement in
3530 but perhaps not stated as succinctly in that document?

nfsv4 mailing list
nfsv4 <at>

Manoj Naik | 21 Jul 21:15 2014

Re: Fw: New Version Notification for draft-naik-nfsv4-xattrs-00.txt


Responses inline based on the new draft we just submitted.


> From: "Haynes, Tom" <Tom.Haynes <at>>
> To: Manoj Naik/Almaden/IBM <at> IBMUS, "nfsv4 <at>" <nfsv4 <at>>,
> Date: 03/04/2014 03:58 PM
> Subject: Re: [nfsv4] Fw: New Version Notification for draft-naik-
> nfsv4-xattrs-00.txt
> Sent by: "nfsv4" <nfsv4-bounces <at>>
> Hi Manoj,
> Please find enclosed my review of your draft.

> 1) S1:
> A lot of claims of wide spread use of xattrs with no citations.
> 2) S1:
> Use case seems to be that it exists, so lets put it on the wire.

I have added a few more use cases. While there are quite a few applications that use xattrs where the underlying file system supports them, I found it was near impossible to find public citations for them. If anybody has references that can be documented, I would be glad to include them.

> 3) S1:
> What is the difference between xattrs and forks?

There is no explicit reference to the term "fork", which have varying implementations. Did you think we should bring out specific differences? The Solaris forks resemble the named attributes of NFSv4 closely, and the section on named attributes in the draft brings out the differences with xattrs.

> 4) S2:
> Please call out in stronger terms why we do only want to allow
> user-managed metadata only to prevent the development of
> non-interoperable implementations. I would actually think that
> the reverse is true.
> I.e., Labeled NFS object labels can be implemented as "security"
> xattrs. By having a well defined set of xattr names, it would
> promote interoperable implementations of seLinux.
> I'd like to see called out that the non-interoperable implementations
> here means that the xattrs are only utilized by the client and not
> the server. I.e., I do not want the xattr implementation to become
> a backdoor to driving new functionality into someone's server.
> And while that would appear to contradict my earlier statement
> about seLinux, the server would be enforcing the object label
> as it retrieved it from the sec_label attribute.
> I'd also like to see how this can be enforced at the protocol level?

Paragraphs 2 and 3 of Section 3 expands on this a bit in the new draft. Neither the client nor the server can interpret xattrs - only the applications can manipulate them (and the backend file system store them). The draft leaves open the option of using specific names to represent well-defined xattrs (such as seLinux) in a future document.

> 5) S3
>    Subsequently, xattrs presumably have size
>    limits ranging from a few bytes to several kilobytes, although this
>    is not universally defined.
> Are you going to define a limit for NFSv4?
> Are there limits on the size of the name?
> Is the name going to ASCII or UTF-8?
> Are there limits to the number of xattrs that can be associated with a fie system object?
> I.e., while a single xattr may be atomic, the collection of them may not.
> I see you develop this a bit in S4, but the reasons for why there are
> limits should be discussed here.

Section 5.1.1 and 5.1.2 now covers this. There is no limit on the size or number of xattrs as long as the request to get/set them can fit in a single RPC. This is similar to what is implicitly accepted for other file attributes such as ACLs - NFS4ERR_REQ_TOO_BIG is used to indicate an error.

> 6) S4
>    A client may ask for any of these attributes to be returned by
>    setting a bit in the GETATTR request but MUST handle the case where
>    the server does not return them.  A client may ask for the set of
>    attributes the server supports and SHOULD NOT request attributes the
>    server does not support.
> What is the server supposed to do if the client asks for xattrs and
> it does not support them?
> Also, this is GETATTR, should it not be GETXATTR or whatever you are
> going to call it?


> 7) S4
> 4.2.1  Attribute 82: xattr_support
>    TRUE, if the object's file system supports extended attributes.
> 4.2.2  Attribute 83: maxxattrsize
>    Maximum size in bytes of all the extended attributes per object that
>    the object's file system supports.
> Do we need both? If maxxattrsize == 0, it indicates that there is no support
> for extended attributes.
> If we need both, what is the defined reaction to these value(s) (including
> xattrsize) being 0?

Fixed - xattr_support removed.

> 8) S4.2.2
> Are there any requirements that the xattr operations be atomic with any
> other operations inside the same compound?

No, in fact there is no requirement that setting multiple xattrs in the same SETXATTR is atomic either. See Section

> 9) S4.2.4
>    Although the client can
>    get and set xattrs, the server is responsible for using the xattrs
>    for its own purposes.
> Again, I'd argue that the server cannot use the xattrs.

Yes, fixed.

> 10) S4.2.4
>    For SETATTR operation, if the
>    associated xattrvalue4 has a length of zero, the corresponding xattr
>    is to be deleted, if it exists.
> Where was xattrvalue4 defined?
> Wait, I see it after this. You might want to define that data structure first.


> 11) S4.2.4
>    Specific names of attributes will not
>    be controlled by this document or other IETF Standards Track
>    documents.
> Perhaps we can limit this to the "user" namespace and leave the
> decision of other name spaces to later documents.


> 12) S4.2.4
>         The NFS xattr structure is defined as follows:
>         typedef utf8str_cis         xattrname4;
>         typedef opaque                xattrvalue4<>;
>         struct xattr4 {
>                 xattrname4     xa_name;
>                 xattrvalue4    xa_value;
>         };
> Do maxxattrsize and xattrsize apply to just the xa_value or to combination
> of xa_value and xa_name?

Combination, now mentioned in Section 5.2.1.

> 13) S4.2.5
> How is the name space encoded inside the xattrname4?

As stated earlier, this draft does not impose restrictions on the xattr name - encoding namespace or defining specific names is left for a future document.

> 14) S4.2.5
>    The xattrnames is similar to xattrs attribute, except that it only
>    returns the names of the xattrs for the file system object without
>    the values. Each xattr is a tuple of the form (name, value).
>    xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is
>    a variable length string that identifies the values of a specified
>    xattr. The NFS client or server must not interpret the value.
> The last two sentences belong before this section. I.e., both
> xattrname4 and xattrvalue4 are also applicable to S4.2.4.

No longer required with the new operations.

> 15) S4.3
> xattrnames is basically a directory read. Do you need an ACE4 to control that?

The two ACE access mask attributes control permissions to GETXATTR/SETXATTR in the new draft.

> 16) Normative references are [RFC5661] and informative ones are [1].
> Please make consistent.
> Also, [KEYWORDS] should be [RFC2119].


> 17) Overall
> If xattrs are allowed to be run on the server, how do they interact with pNFS?
> Is the interpretation only to be on the MDS? Or do the DSes have an impact?

Added a section on pNFS considerations.

> How do xattrs interact with seLinux? I.e., once we get this in NFSv4.x, can
> the object label specify what subject labels are authorized to read/write/list the xattrs?

This draft does not limit on specify the names (or namespace) for xattrs. Perhaps in a future document.

> Finally, based on my experience with Labeled NFS, it might be better for you
> to split off the requirements and the implementation. There were much better
> use cases for Labeled NFS, but it still dragged on until we got the requirements
> gathered in a new document.

We see GETXATTR/SETXATTR as a fairly small extension to the protocol (in the same vein as READ_PLUS/WRITE_PLUS), that having requirements in a separate document may not have enough content and be warranted. The prevalence of xattr support in file systems is well-established, and despite the absence of a standard, their definition and operations are fairly consistent across platforms. Section 5.2 captures the requirements through the new operations.

> Tom
> From: Manoj Naik <mnaik <at>>
> Date: Friday, February 7, 2014 at 8:38 AM
> To: "nfsv4 <at>" <nfsv4 <at>>
> Subject: [nfsv4] Fw: New Version Notification for draft-naik-nfsv4-
> xattrs-00.txt
> I have just submitted a draft proposal to support extended
> attributes in NFS. We've tried to include most of the views
> expressed on the mailing list in the past on this topic, and hoping
> the discussion can continue here, at Connectathon and at London.
> This first draft extends the existing attribute bitmap to include
> xattrs. This is easier to define and implement, but does not allow
> some operations like reading or writing individual xattrs.
> Other options mentioned (but not detailed) are:
> - define new operations - such as GETXATTR and SETXATTR - solely for
> xattrs. Cleaner, but has some consistency issues with GETATTR/SETATTR  
> with respect to attribute caching semantics.
> - define new operations - such as GETATTR_PLUS and SETATTR_PLUS
> (similar to extensions to READ/WRITE proposed for 4.2) - that
> support all the features of GETATTR/SETATTR, but include extensions
> to fully support xattrs.
> Please provide feedback.
> Manoj Naik
> IBM Almaden
> internet-drafts <at> wrote on 02/07/2014 12:16:01 AM:
> > From: internet-drafts <at>
> > To: mnaik <at>, eshel <at>
> > Date: 02/07/2014 12:16 AM
> > Subject: New Version Notification for draft-naik-nfsv4-xattrs-00.txt
> >
> >
> > A new version of I-D, draft-naik-nfsv4-xattrs-00.txt
> > has been successfully submitted by Manoj Naik and posted to the
> > IETF repository.
> >
> > Name:      draft-naik-nfsv4-xattrs
> > Revision:   00
> > Title:      Support for File System Extended Attributes in NFSv4
> > Document date:   2014-02-06
> > Group:      Individual Submission
> > Pages:      10
> > URL:  
> > nfsv4-xattrs-00.txt
> > Status:
> > Htmlized:
> >
> >
> > Abstract:
> >    This document proposes extensions to existing NFSv4 operations to
> >    allow file extended attributes (here forth also referred to as
> >    xattrs) to be manipulated in the protocol. An xattr is a file system
> >    feature that allows opaque metadata, not interpreted by the file
> >    system, to be associated with files and directories and are supported
> >    by many modern file systems. New file attributes are proposed to
> >    allow clients to query the server for xattr support, and get and set
> >    xattrs on file system objects.
> >
> >
> >                                                                            
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at
> >
> > The IETF Secretariat
> > [attachment "draft-naik-nfsv4-xattrs-00.txt" deleted by Marc
> Eshel/Almaden/IBM] _______________________________________________
> nfsv4 mailing list
> nfsv4 <at>
nfsv4 mailing list
nfsv4 <at>
Manoj Naik | 21 Jul 21:13 2014

Fw: New Version Notification for draft-naik-nfsv4-xattrs-01.txt

I've submitted an update to the xattr draft that defines new operations, GETXATTR and SETXATTR, to manage extended attributes. Please provide feedback.

Manoj Naik
IBM Almaden

----- Forwarded by mnaik <at> on 07/21/2014 11:07 AM -----

internet-drafts <at> wrote on 07/20/2014 09:53:07 PM:

> From: internet-drafts <at>
> To: mnaik <at>, eshel <at>
> Date: 07/20/2014 09:53 PM
> Subject: New Version Notification for draft-naik-nfsv4-xattrs-01.txt
> A new version of I-D, draft-naik-nfsv4-xattrs-01.txt
> has been successfully submitted by Manoj Naik and posted to the
> IETF repository.
> Name:      draft-naik-nfsv4-xattrs
> Revision:   01
> Title:      Support for File System Extended Attributes in NFSv4
> Document date:   2014-07-18
> Group:      Individual Submission
> Pages:      16
> URL:  
> nfsv4-xattrs-01.txt
> Status:
> Htmlized:
> Diff: 
> Abstract:
>    This document proposes extensions to existing NFSv4 operations to
>    allow file extended attributes (here forth also referred to as
>    xattrs) to be manipulated in the protocol. An xattr is a file system
>    feature that allows opaque metadata, not interpreted by the file
>    system, to be associated with files and directories and are supported
>    by many modern file systems. New file attributes are proposed to
>    allow clients to query the server for xattr support, and new
>    operations to get and set xattrs on file system objects.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
nfsv4 mailing list
nfsv4 <at>
Tom Haynes | 14 Jul 23:03 2014

RPCSEC_GSSv3/LNFS and NFSv4.2 draft status

Thanks for the edits Andy, I’ve pushed them out.

Having said that, I’m about to nuke the wording on delegations with LNFS. A little birdie
(okay, Trond) pointed out a serious issue with that approach:

> The file I/O operations are the only ones that take delegation
> stateids; the rest can't be protected this way.
> Furthermore, a bunch of operations actually require you to _discard_
> the delegation before execution (e.g. unlink(), rename(), ...) so
> cannot even be protected by implication.

I’m not going to advocate the CB method nor the change_sec_label.

Instead, I’m going to point out the issue, that we don’t have enough data
on how often a label changes (we suspect it is very rare), etc. The client
can grab a new copy of the attribute if it cares. But any other approach
needs to wait until we get implementation experience, which means 4.3.
nfsv4 mailing list
nfsv4 <at>

andros | 14 Jul 21:06 2014

[Version 2 PATCH 1/1] Destroy copy_confirm_auth handle when copy_from_auth destroyed

From: Andy Adamson <andros <at>>

Signed-off-by: Andy Adamson <andros <at>>
 nfsv42_middle_copy.xml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/nfsv42_middle_copy.xml b/nfsv42_middle_copy.xml
index 928758d..844e205 100644
--- a/nfsv42_middle_copy.xml
+++ b/nfsv42_middle_copy.xml
 <at>  <at>  -1058,6 +1058,15  <at>  <at> 

+           The copy_confirm_auth RPCSEC_GSS3 handle is associated with a
+           copy_from_auth RPCSEC_GSS3 handle on the source server via
+           the shared secret and MUST be locally destroyed
+           (there is no RPCSEC_GSS3_DESTROY as the source server is
+           not the initiator)
+           when the copy_from_auth RPCSEC_GSSv3 handle is destroyed.
+          </t>
+          <t>
             If the client sends an OFFLOAD_CANCEL to the source server to
             rescind the destination server's synchronous copy privilege, it
             uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle and the

-- (Apple Git-48)

nfsv4 mailing list
nfsv4 <at>