pNFS in the News

Two recent articles have been posted to web by reporters, which quote me.

The first is by Drew Robb for  Enterprise Storage Forum which I  mentioned in an earlier post. I don't see any major technical inaccuracies, though the article does imply, if not say outright, that the security features added to NFSv4.0 are coming in NFSv4.1.

As I noted before, I cannot comment on the dates Mr. Robb stated for when NetApp would ship pNFS. What I told Mr. Robb was this:

On NFSv4.1, NetApp plans to provide an NFSv4.1 server, starting with
pNFS on a future release of Data ONTAP, leveraging our existing
striped WAFL technology. (Striped WAFL is currently available in Data
ONTAP 10 GX.)

I do want to point out conflicting quotes in the article.

• Mr. Robb quotes Greg Schulz as saying:

"For environments that need improved performance for large, sequential files where parallel access is needed, pNFS has some legs moving forward," said Greg Schulz, senior analyst and founder of StorageIO Group. "However, not every environment or application needs parallel access to data."

• Earlier in the article Mr. Robb quoted me as saying:

"Even for files too small to stripe, those files can be distributed across multiple NFS servers, which provides statistical load balancing," said Eisler. "With a capable cluster of NFS servers and a back-end file system, files or ranges within files can be relocated transparent to the applications accessing data over pNFS."

It would have been interesting if Mr. Robb had asked each interviewee about the conflicting opinion. At any rate, NetApp's experience is that distributing small files in a storage cluster is highly desired by customers. NetApp's competitors have told me the same thing. Hence pNFS will support the "many small files" scenario as wells as the "large, sequential files" scenario.

The second article is by Beth Pariseau for SearchStorage. Ms. Pariseau opens with:

The first fundamental change to the Network File System (NFS) standard in decades -- the Parallel NFS (pNFS) extension -- is currently in the process of ratification with the ANSI T11 standards body.

Actually, the standards body is IETF, specifically the NFSv4 working group. T11 on the other hand is technical committee "responsible for Fibre Channel Interfaces." It is possible Ms. Pariseau meant T10, which is "responsible for SCSI Storage Interfaces." One of things T10 has done which relevant to pNFS is to define extensions to SCSI for supporting Object Storage Devices (OSD). OSD is one of the storage access protocols pNFS supports for accessing data, the other two being NFSv4.1 itself, and pure SCSI as supported by iSCSI and Fibre Channel.

Ms. Pariseau also mentioned the VMware and pNFS angle, suggesting that pNFS would be a way to overcome current ESX limitations that prevent aggregation of gigabit Ethernet links (aka NIC bonding).

Certainly all hypervisor vendors should have a pNFS client on their roadmap: it would be a neat way to automatically parallelize the I/O (and metadata) of  the file systems of legacy guest operating systems that  don't have pNFS (e.g. Windows 2003 guest operating systems use NTFS, which a hypervisor can virtualize today into LUNs or files on a storage server. With pNFS on the hypervisor, the files, directories, block maps, etc. of NTFS would be automatically distributed and striped).

However NIC bonding is a solution to problems that don't exactly intersect the problems pNFS solves. Going down a pNFS-only route in lieu of NIC bonding would lead to cases where single gigabit Ethernet bandwidth between the hypervisor's pNFS client and a storage device is still not enough.

By the way, NFSv4.1, which pNFS is a part of, adds the capability to perform trunking at the NFS level. NFSv4.1 adds a session layer. A client establishes a session with an NFSv4.1 server. The client can create multiple TCP connections to the NFSv4.1 server, each potentially going over a different network interface on the client and arriving on a different interface on the NFSv4.1 server. Now different requests sent over the same session identifier can go over different network paths. I suspect NFSv4.1 trunking has the potential to "steal the show" with respect to current spot light on pNFS within the NFSv4.1 protocol. It will work with or without pNFS. 

At any rate, NFSv4.1 trunking would be a way to obviate NIC bonding. Perhaps that is what Ms. Pariseau was alluding to.