Betting on the future of parallel NFS

Are you using or planning to use NFSv4 (Network File System version 4)? I wouldn’t be surprised if most of the answers to that question are a flat-out no or a quizzical stare, because this latest incarnation of the Linux/Unix file system is still a long way from becoming a mainstream solution. However, let me make it clear that this impasse is not for lack of merit, because NFSv4 has a lot to like.

[ MarioApicella's column is now a blog! Get the latest storage news from the Storage Adviser blog. ]

If you need a refresher or an introduction to NFSv4, I can’t think of a better document than “The Future of NFS,” a presentation given by NetApp’s Mike Eisler at SNIA in 2005. (You may also want to visit Eisler’s blog.)

From that easy-to-follow presentation, you’ll certainly learn more about the protocol than I could possibly squeeze into this column, but here is a quick summary for your boss, quoted from the abstract of RFC 3010, the Internet draft for NFSv4: “Unlike earlier versions, the NFS version 4 protocols support traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added.”

Each of those plainly stated goals is a revolutionary step up from previous versions. Client caching, for example, translates into clients being able to lease file ownership and to freely modify their content locally until the server reclaims ownership. That approach saves contention time between clients and update time over, say, a block-locking alternative where each update is negotiated over the network.

Why the discussion about NFSv4? Blame it on a recent announcement from Panasas, a company we've talked about before. Panasas' intention to make available the source code of its client software, DirectFLOW, suddenly shoves the next version of the NFS protocol (v4.1) into the spotlight.

We need NFSv4.1 because “there is no shortage of applications frustrated by the limitations of a single network endpoint on a single NFS server exporting a single file system or single huge file,” according to a joint 2004 document from NetApp and Panasas that essentially explained the reason to pursue NFSv4.1 to the IETF.

Here in 2007, NFSv4.1 is still being perfected and will eventually cover the much-debated and controversial space of high-performance computing and fast access to large files — an area that previous versions of the protocol simply could not handle. The lack of a viable standard for that high-end segment triggered open source solutions such as Lustre as well as others from vendors such as BlueArc, EMC, IBM, Ibrix, Isilon, NetApp, and SGI, in addition to Panasas.