AI ONTAP NFS pNFS Oct 08, 2026
The product page’s architecture contract
The page describes one namespace over federated ONTAP resources, with metadata separated from data movement. A client asks the metadata layer where a file lives, then accesses the data layer directly. Adding another storage system is intended to add throughput without giving GPU hosts another mount or carving the dataset into another user-visible silo.
The initial implementation named in NetApp’s release is specific: Novus Data Director metadata software runs on qualified Supermicro infrastructure, while ONTAP on AFF A90 systems moves the data. Clients are standard in-kernel NFSv4.2 / pNFS Flex Files clients; the product page also names nconnect and GPUDirect Storage. This is not a generic claim that any NFS mount, Linux release, NIC or AFF system can join a Novus deployment. The validated compatibility matrix still governs.
What ONTAP owns—and what it no longer owns alone
ONTAP remains the data-services and byte-serving layer. AFF A90 nodes contribute capacity and data-path bandwidth, and NetApp says the design preserves ONTAP resiliency, security and multi-tenant services. The new boundary is namespace metadata: directory traversal, file location and client layout work are coordinated by Data Director rather than being coupled to the same controllers that serve every data read.
That boundary changes operations. An AI-factory team must observe three things separately: metadata-service latency and availability, client-to-data-node throughput, and the ONTAP systems’ own latency, CPU, network and capacity headroom. A healthy AFF aggregate does not prove that layout requests are healthy; a responsive namespace does not prove that the GPU hosts are receiving data fast enough. Use the site’s ONTAP performance monitoring guide for the array side, but require Novus-specific telemetry for the metadata tier and clients.
100 TB/s is a design target, not a production result
NetApp’s page says Novus can deliver more than 100 TB/s in one file system and illustrates the demand as 50,000-plus GPUs at roughly 2 GB/s each. The accompanying press release is more precise about the evidence: Omdia audited near-linear scaling as ONTAP clusters were added, then modelled the disaggregated design to 100 TB/s sequential reads and dozens of exabytes. NetApp’s own footnote says anticipated features and timing can change.
So the defensible reading is: the architecture is designed to scale metadata, bandwidth and capacity independently, and a witnessed test informed the projection. It is not evidence of a deployed 100 TB/s system, mixed-workload latency, checkpoint performance or a particular GPU-utilisation gain. Procurement should ask for the audited node count, client count, file-size distribution, read/write mix, failure behaviour and sustained—not peak—results.
Five checks before treating Novus as an ONTAP extension
- Freeze the supported client image. Record the Linux kernel, NFS client, NIC, firmware, RDMA/GDS components and mount options validated together. NetApp says no proprietary client is required; that does not remove version dependencies.
- Test each failure plane. Pull a metadata node, an AFF HA pair, a client path and a network switch separately. Capture client-visible stall time, retry behaviour and recovery without remounting.
- Prove tenant isolation. Verify where identity, export policy, QoS and namespace controls are enforced, especially when a single namespace spans multiple ONTAP clusters.
- Benchmark the actual pipeline. Include billions-of-files metadata pressure, random sample reads, checkpoint writes and concurrent tenants—not only large sequential reads.
- Keep the support boundary explicit. The product page says the data layer is AFF A90. Do not infer support for other ONTAP platforms or a software-defined deployment until NetApp publishes the corresponding configuration and availability.
Novus therefore adds an orchestration and metadata plane above ONTAP; it does not turn every existing ONTAP NFS environment into an AI-factory file system. For the deeper component and failure-domain analysis, see our Novus Data Director and AFF A90 explainer. For baseline protocol concepts, see the ONTAP NFS reference and network architecture guide.
Bottom line
The concrete product change is a standards-based parallel-NFS front end that federates ONTAP data nodes beneath one namespace and lets metadata scale separately. That is technically meaningful. The 100 TB/s headline is still a modelled scale claim, and ONTAP teams evaluating Novus need a new runbook that covers Data Director, clients and fabric as well as AFF.
Read the source (NetApp Novus) · Read the NetApp press release · Technical deep dive