Subject: [nfsv4] Results of interim meeting discussion of NFSv4.2

From: Spencer Shepler <[email-masked]>
Date: Sun, 6 Mar 2011 19:51:02 +0000

At the interim meeting, we discussed NFSv4.2.  This message is a
summary of that discussion, a plan for next steps, and a further
determination of rough consensus within the broader scope of the WG
alias.

Our current working group charter includes maintenance of NFSv4.0,
NFSv4.1, and the RPC/XDR protocols.  With completion of the Federated
Namespace I-Ds, that charter item will move to maintenance.

The discussion and consensus at the interim meeting was to add a
working group charter item for the development of NFSv4.2. 

The group reviewed a set of options for how best to manage NFSv4.2
content and timeline.  The eventual conclusion was to focus NFSv4.2 as
a time limited deliverable.  The premise is that solid proposals exist
today for NFSv4.2.  Setting a deadline for NFSv4.2 delivery will act
as a forcing function to complete existing proposals and if other less
mature proposals reach a similar level of maturity, they can be
included in NFSv4.2 as well.

The timeline chosen during the meeting was 1 year; for example,
NFSv4.2 ready for working group last call by March 2012.

The next topic was what physical form NFSv4.2 would take.  An NFSv4.2
RFC will not document the entire protocol.  NFSv4.2 will build from
the NFSv4.1 RFC and note only the functional additions or semantic
clarifications required to build NFSv4.2.  NFSv4.2 may or may not be
multiple RFCs.  That determination will be made later based on content
scope and document size.

The discussion then moved to content.  The highest priority items
are bug fixes for NFSv4.1; these are more than just errata.
The current bug list is:

  - pNFS Access Permissions Check (has I-D)
  - LEASE_MOVED callback
  - Change attribute semantic description (I-D needed)

So, these bugs may take the form of new operations or semantic changes
that require the minor version update.  Note that NFSv4.2 will abide 
to RFC5661's Minor Version rules as defined in section 2.7.

Those in attendance discussed all of the outstanding functional
proposals -- those in the form of personal I-Ds at the time of the
meeting.  The intent of this discussion was to determine level of
proposal completeness and current energy/interest.  Of all proposals,
the following were considered to be most appropriate for NFSv4.2 at
this time.

- NFS Server-Side Copy
- Simple and efficient read support for sparse files
- NFS space reservation operations
- RPCSEC GSS v3 (needed for NFS Server-Side Copy)

The goal of identifying the list above is two-fold.  First, provide
direction to those in the working group as to where our collective
energy should be placed.  Second is to have content for the necessary
working group charter update.  As mentioned above, this is not meant
to be exclusionary.  Other work items may be included in NFSv4.2 as
well if the required level of interest and maturity are reached.

To that end, the following set of proposals had interest but level of
maturity was less than desired.  There is potential for NFSv4.2
inclusion but these will not be the initial focus items.

- NFSv4.2 Unstable File Creation
- NFSv4 pNFS Back End Protocol Extensions
- Extending NFS to Support Enterprise Applications
- Storage Control Extensions for NFSv4
- Fadvise (from original NFSv4.2 requirements -- need I-D)

Finally, the next set of proposals seem to lack both energy and maturity.

- MAC Security Label Support for NFSv4
- NFS Pathless Objects
- Storage De-Duplication awareness and sub-file caching in NFS
- Metadata striping for pNFS

Beepy and I have asked Tom Haynes to be the editor of NFSv4.2 and he
has accepted that responsibility.

Beepy and I will be working with our area directors on the required
text and charter milestone updates for the NFSv4 working group.  We
will cover the detail of the charter update during our meeting in
Prague.  The goal is to provide our area directors the insight and
detail needed to represent our work with the remainder of the IESG.

There is an item that falls outside of NFSv4.2; it is of interest to
our working group but spans multiple groups within the IETF and an
exact home is unclear.  I am referring to the NFSv4 Multi-Domain
Access drafts that Andy Adamson has been working on.  I am going to
propose that the NFSv4 WG take this on as a charter item as well and
will include the item into our charter update.

---

From: Thomas Haynes <[email-masked]>
Date: Sun, 6 Mar 2011 23:12:43 -0600

> - Extending NFS to Support Enterprise Applications

I was looking at this today and I'd like us to pull in the Enterprise Applications ID for two reasons:

1) The whole discussion of zero fill being a subcase of pattern fill.

2) If we add this in NFSv4.3, that will mean that we will be adding our 3rd WRITE/READ operation
implementations.

I'd prefer we plan ahead and only take one hit to this area.

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

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Mon, 7 Mar 2011 13:56:11 -0800

> -----Original Message-----
> From: Haynes, Tom
> Sent: Sunday, March 06, 2011 9:13 PM
> To: Spencer Shepler
> Cc: [email-masked]
> Subject: Re: [nfsv4] Results of interim meeting discussion of NFSv4.2
> 
> 

IIRC, Dean already had an AI to go back and look into adding this
support in READPLUS.

> 
> 2) If we add this in NFSv4.3, that will mean that we will be adding
our
> 3rd WRITE/READ operation

Yes, that was precisely what was highlighted in the Interim meeting.
Whether it's pulling the whole enterprise apps document or shrink-to-fit
to just describe the pattern in READPLUS needs to be decided.

-Pranoop

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 7 Mar 2011 17:15:23 -0600

> to just describe the pattern in READPLUS needs to be decided.

The Enterprise Apps WRITE/READ also are being modified to allow
larger buffers, i.e., 64 bit data lengths. And they will eventually support
the IO advice.

Instead of concentrating on whether READPLUS can accommodate
patterns, I'd prefer we merge the two READ proposals to get full
functionality now and not have to make changes in 4.3.

I'm willing to do that work.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 7 Mar 2011 23:21:00 +0000

If including ideas/approaches described in the Enterprise Applications I-D
stand are their own and mesh well with other content that has momentum,
that is fine with me.  Including it mainly on the basis that we want to
avoid work in the future, that is not okay with me.

There needs to be a lot more discussion, review of the content in the
Enterprise Applications I-D before it is ready, IMO.  Let's have that
discussion and if it goes well, then it will logically fit into the NFSv4.2 work.

Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Haynes
Sent: Monday, March 07, 2011 3:15 PM
To: Erasani, Pranoop
Cc: Haynes, Tom; [email-masked]
Subject: Re: [nfsv4] Results of interim meeting discussion of NFSv4.2

I was looking at this today and I'd like us to pull in the Enterprise
Applications ID for two reasons:

3rd WRITE/READ operation
implementations.

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 8 Mar 2011 08:30:06 -0800

The enterprise apps draft allows for the possibility that a string of
zeroes is only one possible pattern for how a hole in file is represented.

People with lots of experience with data corruption have concluded that a
zero is not a good way to represent a hole.

In the interest of generality, allowing hole punching with non-zeroes, and
allowing sparse reads with non-zeroes is a good thing.

And avoiding work is always a good thing.

In addition the enterprise apps I-D provides mechanisms for improved
cached behavior. We've discussed in the past that we want to signal the
client or apps intent for I/O. Now we have a proposal for doing it, and a
proposer interested in developing a product that uses it.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 8 Mar 2011 17:10:37 +0000

> From: Mike Eisler [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2011 8:30 AM
> To: Spencer Shepler
> Cc: [email-masked]

I agree with all of these, Mike, with the exception of the "avoiding work"
argument.  Yes, it is always good to avoid work.  I am trying to be
careful about setting precedence for determining additions to NFSv4.2.
At this moment, we are a 12 months from our self-imposed deadline.
When that time shrinks, I don't want the "it will avoid work" argument
to be used to add things to NFSv4.2.  The consensus during the meeting
was that we didn't want a never ending protocol definition.  I am being
pedantic because I want merit, interest, maturity of proposals to guide
our decisions.

Just to be clear, I am okay with adding the enterprise work to NFSv4.2.

My attempt is to clarify the reasons why.

Spencer

> > If including ideas/approaches described in the Enterprise Applications
> > I-D stand are their own and mesh well with other content that has
> > momentum, that is fine with me.  Including it mainly on the basis that
> > we want to avoid work in the future, that is not okay with me.
> >
> > Whether it's pulling the whole enterprise apps document or
> > shrink-to-fit to just describe the pattern in READPLUS needs to be
> decided.
> >
> > The Enterprise Apps WRITE/READ also are being modified to allow larger
> > buffers, i.e., 64 bit data lengths. And they will eventually support
> > the IO advice.
> >
> > Instead of concentrating on whether READPLUS can accommodate patterns,
> > I'd prefer we merge the two READ proposals to get full functionality
> > now and not have to make changes in 4.3.
> >

---

From: Dean <[email-masked]>
Date: Mon, 14 Mar 2011 14:48:08 -0700

> IIRC, Dean already had an AI to go back and look into adding this
Yes, my understanding form the meeting was that this proposal had great 
ideas but wasn't quite flushed out as of yet.  But since it was an 
obvious addition, I was to work with Mike/Tom to incorporate a pattern 
(instead of all zeroes) into the READPLUS operation.

I unfortunately cannot make IETF 80 as travel restrictions are in place 
for this quarter.  I don't think I've seen an IETF presentation on the 
latest draft of the Enterprise Applications ID, so I'm a little out of 
touch on the specific operations/changes it proposes.

I just returned from vacation, so I'm a little late to this thread.  
 From a quick glance at the draft, I have 2 questions,
1) Are the proposed operations all improving/creating a single feature, 
or is a set of enhancements that could be divided into several different 
drafts, each proposing a solution to a different usecase/problem.

2) The IO_ADVISE and XX_ADVICE ops seem to overlap a lot with posix 
fadvise 
(http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fadvise.html).  
Some discussion on the relationship would be very helpful.  I don't 
think we want to get ourselves into a mapping issue a la ACLs.  In 
addition, I had another todo on my plate to write the fadvise draft 
before IETF80.  Another option might be to simply work with authors of 
the Enterprise Applications ID to ensure fadvise (and O_DIRECT) can be 
successfully implemented.  Or maybe we move all FADVISE (hint) related 
items into a separate draft.

On this point, I found an interesting paper we should read (or even 
readplus):
http://www.usenix.org/event/usenix09/tech/full_papers/vandebogart/vandebogart.pdf

Dean