Christoph Hellwig | 16 Aug 16:35 2014

[internet-drafts <at> New Version Notification for draft-hellwig-nfsv4-rfc5663bis-00.txt]

I've published a first attempt at starting the bis process for rfc5663.

The major driver for this was that rfc5663 entirely ignores the concept
of volatile write caches on storage devices.  This draft adds simple
language that requires the server to ensure data is on stable storage
after a LAYOUTCOMMIT returns.

The other non-housekeeping change is a much stricter language in section
2.3.5. to enforce the single writer XOR multiple readers exclusion.  The
current text contains a lot of mays but ignores that fact that block devices
generally do not allow byte level access, and thus the server mus
ensure that multiple read-modify-write cycles don't step on each others

----- Forwarded message from internet-drafts <at> -----

Date: Sat, 16 Aug 2014 03:12:27 -0700
From: internet-drafts <at>
Subject: New Version Notification for draft-hellwig-nfsv4-rfc5663bis-00.txt
To: Christoph Hellwig <hch <at>>, Christoph Hellwig <hch <at>>

A new version of I-D, draft-hellwig-nfsv4-rfc5663bis-00.txt
has been successfully submitted by Christoph Hellwig and posted to the
IETF repository.

Name:		draft-hellwig-nfsv4-rfc5663bis
Revision:	00
Title:		Parallel NFS (pNFS) Block/Volume Layout
Document date:	2014-08-16
Group:		Individual Submission
(Continue reading)

Fred Isaman | 31 Jul 16:03 2014


This popped up on the linux client, but is a general protocol question...

What is the client supposed to do when it receives an error (in this case ADMIN_REVOKED or BAD_STATEID) to an OPEN(CLAIM_DELEGATE_CUR) sent during delegation return?

One option is to try to OPEN(CLAIM_NULL) the file and dump local data, but that (and pretty much every other option I've come up with) seems a recipe for data corruption.

nfsv4 mailing list
nfsv4 <at>
Adamson, Andy | 30 Jul 16:47 2014

draft-ietf-nfsv4-rpcsec-gssv3: request for review


I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the
RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews.  Please review the draft
which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2.

As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014.


ā€”>Andy Adamson
nfsv4 mailing list
nfsv4 <at>

Brian Reitz | 28 Jul 23:28 2014

4.2 COPY op questions

I raised a question about the 4.2 server-to-server copy spec language wrt delegations during IETF 90. 
Specifically a write delegation.  I committed to taking that question to this list for more discussion.  

If the client that has initiated a server-to-server copy holds a write delegation it may also hold
unwritten data that the source server has not seen.  If the COPY op does not cause a delegation recall the
client would need to ensure that this unwritten data is flushed prior to initiating the copy.  That might be
a quality of implementation detail.  The possibility exists to use NFSv4.x as the Copy Protocol.   If an
implementor was going to use NFSv4.x as the Copy Protocol, a general client implementation on the
destination server doing a read might reasonably expect the source server to initiate a deleg recall,
unless it is expected that the READ on the destination server can skip the OPEN by using arguments in the
COPY op.   I think it would be helpful if the spec had additional clarifyi
 ng language here detailing the expected behavior and relationship to delegations.

I also have a question around the stateids that are passed to the destination server in a COPY op:

     4.7.2.  Using NFSv4.x as the Copy Protocol

     The destination server MAY use standard NFSv4.x (where x >= 1)
     operations to read the data from the source server.  If NFSv4.x is
     used for the server-to-server copy protocol, the destination server
     can use the source filehandle and ca_src_stateid provided in the COPY
     request with standard NFSv4.x operations to read data from the source

I believe that this spec language is talking about what an implementer MAY do, and how these stateids might
be used.  I think it may also be helpful to have additional clarifying language here indicating the
different scoping of a stateid.  The implication to the implementor here is that these stateids can be used
by multiple clients.  That is something that is not required by 5661.  From 5661 section 8.2:

    The server may assign stateids independently for different clients.
     A stateid with the same bit pattern for one client may designate an
     entirely different set of locks for a different client.  The stateid
     is always interpreted with respect to the client ID associated with
     the current session.  Stateids apply to all sessions associated with
     the given client ID, and the client may use a stateid obtained from
     one session on another session associated with the same client ID.

It might be helpful to clarify that the stateids passed in the COPY would need to be implemented such that
they had a broader scope than what is detailed in 5661.


nfsv4 mailing list
nfsv4 <at>

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.

Internet Draft Comments

   Comments regarding this draft are solicited.




Matt Benjamin
CohortFS, LLC.
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309 

nfsv4 mailing list
nfsv4 <at>

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.


nfsv4 mailing list
nfsv4 <at>

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>