NetApp - Eisler's NFS Blog

NFSv4.1 has an RFC number

I just received word from IETF's RFC Editor that NFSv4.1 has entered the "AUTH48" status, which used to mean 48 hours to given an RFC author a last chance to update the RFC before publication, but now means, that the document's publication is on hold until the authors give it the go ahead. Given that is has been 10 months since IETF approved NFSv4.1 for publication, the NFSv4.1 community has found many typos and other errors in the document, so I will be spending lots of time between now and the end of the year reconciling what the community has changed with what the RFC editor has changed. My goal is for NFSv4.1 to be published as an RFC this calendar year, 2009.

NFSv4.1 client is now in official Linux kernel repository

My co-worker (and co-author) Ricardo Labiaga, just told me:

The NFS v4.1 client has been officially integrated into the upstream Linux kernel repository!  It will be part of the Linux kernel version 2.6.31.  We should see a release candidate before the end of this week.  The Linux NFS v4.1 client implements the Sessions functionality, laying the foundation for pNFS to be submitted in the next few months.

This is a major milestone for the Linux NFS client development community (consisting of a group that includes developers like Ricardo from NetApp, EMC, IBM, Panasas, and the University of Michigan) and for NFSv4.1. Congratulations!

ONC RPC is now a Draft Standard

Another RFC, another time to post in fixed width.

Just to re-cap, Internet RFCs which are standards-track, come in three flavors (maturity levels):

• Proposed - entry level, zero to little experience
• Draft - at least two unique and interoperable implementations
• Internet Standard - more implementation experience, and 4 months have elapsed since Draft status was established

ONC RPC (the remote procedure call protocol that NFS uses) has been at Proposed since 1995, when Raj Srinivasan of Sun was the editor who guided the process of moving ONC RPC into IETF's hands.

On May 4, 2009, IETF announced that Rob Thurlow's (of Sun) editing work to make ONC RPC a Draft Standard was done, and as a consequence RFC5531 is now available. Congratulations to Rob.

Hopefully, Internet Standard status will not be far behind. RPC can then join XDR in an exclusive club of full standards.

Microsoft announces an open source NFSv4.1 client

This announcement was made on April 22, 2009. I've been busy getting ready for an overseas trip, and once overseas found my hotel had a lax approach to Internet service (when one is in a hotel filled with hundreds of vacationers, beware the phrase "the hotel WiFi is free": the Tragedy of the Commons kicks in with a vengeance) so regrettably am not commenting until today.

Microsoft is partnering with the University of Michigan's Center for Information Technology Integration to produce an NFSv4.1 client for Windows. Bob Muglia of Microsoft is quoted as:

“NFSv4.1 is an important standard for accessing parallel file systems in the high-performance computing market, where access to vast amounts of data is critical in areas like scientific or technical computing systems."

Emphasis mine.

A couple quick comments.

• First, I congratulate Microsoft on expanding its presence in the NFS industry. It only makes sense that one of the largest software companies in the world step up its investments in the only open standard file access protocol (joining other software giants like IBM and Oracle).
• Second,  I've pointed out before, NFSv4.1 and NFS should not be pigeon holed into narrow markets. Anything that works well with NFSv3 and NFSv4.0 will work well with NFSv4.1. Anything that works well with NFS will work well with pNFS. Business applications like Oracle database today run well over NFS, and I expect they will run even better over pNFS.

Just as CITI has been obliged to do with its Linux NFSv4.0 and NFSv4.1 client efforts, I hope that the code it produces for Windows is as equally adept at supporting all classes of workloads and applications.

Here is something that should be possible with NFSv4.1 and I suspect is on many storage consumer's wish list: Microsoft Exchange support over NFS. That would be really stepping it up!

Attending two Storage Conferences this week

This week, Connectathon and FAST are running.

Yesterday I presented an update on the NFSv4 working group at IETF at Connectathon.

Today at Connectathon, (as I type), Pranoop Erasani is presenting a description of NetApp's pNFS server for Data ONTAP. Tomorrow, I've schedule to co-present with other storage vendors (icnluding EMC, Panasas, and Sun) at the pNFS BOF at the FAST 2009 Conference.

The Connectathon presentations will be available at http://www.connectathon.org/talks09/index.html .

Information about the pNFS BOF at the FAST conference is at http://www.usenix.org/events/fast09/bofs.html#pnfs .

Chuckle for today

Bryan Cantrill of Sun made a scathing indictment of the SPEC SFS benchmark earlier this week. I infer from Bryan's post that Sun's Fishworks team will not be posting SPEC SFS numbers.

My reactions:

• Of course SPEC SFS does not model every real workload. No benchmark can model every customer's needs. Show me one million storage customers, and I'll show you one billion workloads (assuming you'll give me the storage to capture all the packet traces). You have to pick one, and start there for a basis for comparison.
• About eight years ago Brian Pawlowski made the observation to me that those who criticize the SPEC SFS benchmark and instead attempt to push their own custom benchmark methodology are those who are probably producing SPEC SFS numbers that are not good enough to publish.
• As a corollary to the above two points, if a vendor can't excel at SPEC SFS, it probably can't excel at much else. SPEC SFS performance is the minimum bar for entry into the NAS business.
• SPEC's benchmarks are a product of the efforts of the companies that contribute. From our association at Sun, I know Bryan Cantrill is a very smart guy. Last I checked, Sun was still a member of SPEC and the SFS subcommittee. I'm sure the subcommittee could use his contributions on the follow on to SPEC SFS 2008.
• On the lack of a price/performance metric in SPEC SFS. Back in 1992 when LADDIS was being worked on, I recall this was a topic of discussion. The reason why the price/performance metric was not added was because:
1. Like many industries, few storage companies have fixed pricing. As much as heads of sales departments would prefer to charge the same highest price to every customer, it isn't going to happen. Storage is a buyers' market. And for storage devices that serve NFS and now CIFS, the easily accessible numbers on spec.org are yet another tool for buyers. I just don't understand why a storage vendor would advocate removing that tool.
2. In storage, the cost of the components to build the device falls continuously. Just as our customers have a buyers' market, we storage vendors are buyers of components from our suppliers and also enjoy a buyers' market. Re-submitting numbers after a hunk of sheet metal declines in price is silly.

• On caching .... Tom Haynes made a comment that NetApp appears to agree with Bryan's assertion that because SPEC SFS does not encourage external caching, vendors do not sell external caches. Actually, for about a year now NetApp has been selling external cache appliances. And NetApp is not the only storage vendor with an external cache appliance. In Bryan's post we see that ACCESS operations were increased in the SPEC SFS 2008 workload relative to SPEC SFS 3.0. I can't seriously think that Bryan believes storage vendors want to handle more ACCESS calls. The percentage increased between 3.0 and 2008 because customers switched from NFS clients that had a good internal cache of ACCESS results to ones that did not. I.e. customers stopped using Solaris NFS clients. This was unfortunate for Sun, but believe me, it was unfortunate for NetApp too ... I'm still having nightmares from last fall's customer escalation caused by a really bad ACCESS cache on the client. But nonetheless, the philosophy of SPEC SFS has always been to model reality as opposed to the idealist reality dream where a storage device never has to process a request. P.S., in an earlier blog post, I made the argument that SPEC SFS 2008's differences from SPEC SFS 3.0, show the caching on NFS clients has improved.

SuperComputing 2008 Slides from Multivendor presentation posted

NetApp, CITI (University of Michigan), EMC. IBM, LSI, Panasas, StorSpeed, and Sun co-hosted a BOF at SC08 last month.

Our presentation has been posted at http://pnfs.com/docs/sc08_pnfs_bof_slides.pdf .

It's Official: NFSv4.1 Approved for Proposed Standard

IESG just sent the announcement. IESG also approved three of the companion documents (the XDR description of NFSv4.1, the blocks-based pNFS layout, and the objects-based pNFS layout).

 

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20081219154356.CF25D28C101@core3.amsl.com>
Date: Fri, 19 Dec 2008 07:43:56 -0800 (PST)
Cc: nfsv4 chair <nfsv4-chairs@tools.ietf.org>,
     Internet Architecture Board <iab@iab.org>,
     nfsv4 mailing list <nfsv4@ietf.org>,
     RFC Editor <rfc-editor@rfc-editor.org>
Subject: [nfsv4] Protocol Action: 'NFS Version 4 Minor Version 1' 
     to Proposed Standard

The IESG has approved the following document:

- 'NFS Version 4 Minor Version 1 '
   <draft-ietf-nfsv4-minorversion1-29.txt> as a Proposed Standard

This document is the product of the Network File System Version 4 
Working Group. 

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-29.txt

Technical Summary

This Internet-Draft describes NFS version 4 minor version
one, including features retained from the base protocol and
protocol extensions made subsequently. Major extensions
introduced in NFS version 4 minor version one include:
Sessions, Directory Delegations, and parallel NFS (pNFS).

Working Group Summary

This document is the result of long construction, review, and
prototyping. While not all features of NFSv4.1 have been
prototyped or implemented the mainline features have received
reasonable prototyping.

Document Quality

The NFSv4.1 specification was subjected to a series of formal
reviews or walk-throughs that resulted in close review and
resultant issues and resolutions. As a result, the NFSv4.1
documents are complete and of reasonably high quality.
Note to RFC Editor
 
Personnel

Brian Pawslowski (beepy@netapp.com) is the document shepherd.
Lars Eggert (lars.eggert@nokia.com) reviewed the document for the 
IESG.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

IESG's Review of NFSv4.1 is Done

The IESG (Internet Engineering Steering Group) has completed its review the NFSv4.1 specification. The Co-Chair of the NFSv4 Working Group, Spencer Shepler, just sent out this announcement to the Working Group:

The IETF announcement of their approval is pending and then
they will move on to the RFC editor queue for final publication.

We are DONE!

Regarding the last sentence, in my, very recent experience, the RFC Editor can make lots of editorial changes even for a small document. Given this is a 600+ page document, my work is not quite done, but nonetheless this is a great milestone.

Watch this space for the official IETF announcement.

Two Conferences Covering pNFS Next Week

Super Computing 2008 (SC08) in Austin and IETF in Minneapolis are next week. At  SC08, several storage vendors supporting pNFS will host a Birds of a Feather (BOF)meeting. The BOF is scheduled for November 19, 2008, 5:30-7:00 pm in Ballroom F of the Austin Convention Center. In addition NetApp will have a booth at SC08.

Unfortunately, IETF and other obligations prevent me from attending SC08. Joshua Konkle is scheduled to represent NetApp at the pNFS BOF.

At IETF I am scheduled to present an update on Federated FS (standing in for James Lentini), and my proposals for de-dupe awareness and pNFS metadata striping.