If you’ve ever witnessed a high-core-count compute node saturate a single NFS mount point while the rest of a PowerScale cluster still has plenty of resources to spare, you’ve experienced the fundamental limitation that Parallel NFS (pNFS) was designed to eliminate. Traditional NFS, whether NFSv3 or NFSv4.1 in conventional mode, binds all client I/O to the single node behind the mount IP. The cluster may have dozens of nodes, petabytes of aggregate flash bandwidth, and a 400GbE back-end fabric, but from the perspective of that NFS client, it’s talking to one node. With OneFS 9.15, PowerScale introduces native pNFS support, allowing a single NFS client to read and write data directly and concurrently across multiple nodes in a SmartConnect pool — turning the entire cluster into a parallel data path rather than routing everything through a single server. This article covers what pNFS is, how the metadata-server and data-server roles work in a OneFS environment, the prerequisites you need to meet before enabling it, and the CLI steps to activate and configure pNFS on your cluster.
The pNFS protocol is an extension of NFSv4.1, designed to significantly improve throughput for NFS workloads by enabling clients to perform data reads and writes directly and concurrently to multiple nodes across a cluster or distributed storage system, rather than routing all I/O through a single, node-bound NFS server.
In a traditional NFS deployment, a client mounts a share and directs all read and write operations to the single node associated with the mount IP address, which inherently limits performance and creates a bottleneck regardless of overall cluster size or capability.
All I/O for this mount is between the client and node over NFSv3 or NFSv4.1, while the remainder of the cluster’s nodes sit idle for this client.
In contrast, when pNFS is enabled, the client continues to communicate with a single node on the cluster for metadata operations such as file open, close, rename, and attribute queries, but is explicitly informed which other nodes to send the actual file data to.
With OneFS 9.15, any node in a PowerScale cluster can now act as the OneFS metadata server (MDS), or serve data connections (DS). This separation of the metadata path from the data path allows file I/O traffic to be distributed across multiple nodes in the cluster, thereby maximizing available bandwidth and parallelism.
In a pNFS-enabled PowerScale cluster, the client always talks to the MDS over NFSv4.1 or NFSv2 for namespace, attributes, and locking, and it talks directly to data servers for the actual I/O.
- When a pNFS client opens a file, it sends an NFSv4.1 ‘OPEN’ and ‘GETATTR’ to the MDS, which returns a filehandle and any required state.
- The client then issues a ‘LAYOUTGET’ to the MDS, which responds with a layout describing exactly which Data Servers (DSs) hold which byte ranges or stripes of the file, often using a ‘files’ layout with per-node NFS file-handles or device IDs. The client may also send a ‘GETDEVICEINFO’ request, to which the MDS responds.
- For reads, once the client has this layout, it bypasses the MDS and issues NFS ‘READ’ RPCs directly to the Data Servers corresponding to the required byte ranges. The DSs return data straight to the client, while the MDS is only involved again if there is a layout error or a recall, in which case the client may perform ‘LAYOUTCOMMIT’, ‘LAYOUTRETURN’, and a fresh ‘LAYOUTGET’ to resynchronize.
For writes, the client similarly acquires a read-write layout via ‘LAYOUTGET’ from the MDS, then sends NFS ‘WRITE’ (and, if needed, ‘COMMIT’) operations directly to the DSs based on the stripe mapping in the layout.
- After the Data Servers have durably stored the data, the pNFS client uses ‘LAYOUTCOMMIT’ to inform the MDS about changes such as the updated file size and modification time.
- Finally, the client passes a ‘LAYOUTRETURN’ when it is finished with the layout.
Throughout this process, all metadata operations, including directory lookups, creates, deletes, renames, attribute changes, and locks, are handled solely by the MDS using standard NFSv4.1 operations (i.e. LOOKUP, CREATE, REMOVE, RENAME, GETATTR, SETATTR, LOCK, and LOCKU, etc). In contrast, the Data Servers never see namespace, simply serving or accepting data for extents identified by the layout. The net effect is that metadata and control traffic (opens, layouts, locks) flow between the client and the MDS, while bulk data reads and writes flow directly between the client and multiple DS nodes in parallel, allowing the data path to scale with the number of storage nodes rather than being bottlenecked by a single NFS server.
The primary benefits of pNFS include increased single‑client throughput by eliminating the single‑node bottleneck and distributing I/O across all nodes within a SmartConnect pool, as well as improved aggregate cluster throughput through more balanced I/O distribution and better utilization of existing caching and prefetch mechanisms. This functionality is transparent to applications, as pNFS negotiation occurs automatically between the Linux NFS client and the OneFS NFS server without requiring application‑level changes. Because OneFS provides a single distributed filesystem in which every node inherently has access to all data, pNFS simply authorizes the client to communicate directly with additional nodes for data transfer.
When a pNFS‑capable client mounts an NFS export on a pNFS‑enabled OneFS cluster, each node functions as both a Metadata Server and a Data Server, with the Metadata Server role being implicitly assigned to the node the client initially contacts during the mount. Data I/O operations are performed using NFSv3, as permitted by the pNFS Flexible File Layout specification, while NFSv4.1 or NFSv4.2 is used exclusively for layout management and metadata operations. Layouts are granted on a per‑file basis, with the client requesting a layout upon file open that specifies the appropriate data server or servers for that file. Different files may be assigned to different nodes, and traffic distribution behavior is influenced by server‑side alignment settings. The set of data server addresses provided to the client is determined by the SmartConnect pool associated with the mount IP address.
Several prerequisites must be met prior to enabling pNFS on a PowerScale cluster:
| Attribute | Details |
| OneFS version | OneFS 9.15 to provide pNFS support. |
| NFS protocol versions | NFSv4.1 or NFSv4.2 must be enabled (for the metadata path). NFSv3 must also be enabled (for the data path). |
| SmartConnect pool type | The SmartConnect network pool hosting pNFS must use Static IP allocation. |
| Client OS | Linux with kernel pNFS Flexible File Layout support (available in mainline Linux kernels 5.14+). |
| Client mount options | The client must mount the cluster export using NFSv4.1 (-o vers=4.1) or NFSv4.2 (-o vers=4.2). Transport protocol may be RDMA (proto=rdma) or TCP (proto=tcp). UDP is unsupported. |
In the next article in this series, we’ll look at the process to enable and configure pNFS on a PowerScale cluster.