Lattice's developers still call it an early release, and NetApp has disclosed no price, close date or product date for the open-source metadata server.
NetApp said on September 25, 2026, that it intends to acquire PEAK:AIO, a storage-software company based in Manchester, UK. The release describes metadata services that scale independently of data, a global namespace, and parallel NFS access, all of which will be folded into NetApp's ONTAP-based architecture. The deal has not closed. NetApp disclosed neither the price nor the timing, and the release says completion depends on customary closing conditions and regulatory approvals, without naming a regulator. Arindam Banerjee, NetApp's chief platform and technology officer, declined to give CRN either figure, saying financial and integration details would come at close.
The release names no product. Banerjee told CRN that NetApp is very interested in Lattice, and StorageReview identifies pNFS Lattice as the most important piece of PEAK:AIO's metadata work. Lattice is an open-source metadata server for NFSv4.2 that PEAK:AIO initiated and developed with Los Alamos National Laboratory (LANL) and Carnegie Mellon University.
For supercomputing centers and GPU clusters that now share storage problems, the useful question is whether moving file-system metadata to its own scalable tier increases application throughput and keeps accelerators busy under realistic workloads. No such measurement appears in the sources SCN reviewed. The project's own README calls Lattice an early release and says it is "not yet recommended for production use without independent validation, security review and operational testing in your own environment."
Parallel NFS arrived with NFSv4.1 more than a decade ago. It splits a file system into two roles. A metadata server (MDS) handles the namespace (opening files, creating and deleting them, handing out locks) and tells clients where the data lives, and separate data servers then move the bytes directly to clients in parallel. ONTAP already works this way. NetApp's documentation describes an MDS path for metadata operations and localized data paths to files, and its planning guide says pNFS works with both FlexVol and FlexGroup volumes. NetApp's AFX disaggregated system, announced in October 2025, lists pNFS among its supported protocols alongside NFS, SMB, S3 and NFS over RDMA.
The Lattice project says traditional pNFS metadata designs are limited by a single fixed server, and that is the limit it sets out to remove. Data paths widen as servers are added, but every create, stat, and delete still goes through the MDS. AI training pipelines that read millions of small files lean hard on that path, as do checkpoint-heavy simulation codes. Parallel file systems such as Lustre answered this years ago with multiple metadata targets. Lattice aims to provide the Linux kernel's standard NFS client with a comparable answer, without requiring a proprietary client to be installed.
The architecture diagram in the repository README shows three tiers. Several metadata server daemons run in Linux user space and share a single catalog held in RonDB, a distribution of MySQL NDB Cluster. Clients find the MDS responsible for a given part of the namespace through standard NFSv4 referrals (the fs_locations attribute and the NFS4ERR_MOVED error). The data servers are unmodified Linux kernel NFS servers (knfsd), and the MDS hands clients Flex Files layouts, the pNFS layout type defined in RFC 8435, that point them at those servers over TCP or RDMA.
Gary Grider, who leads LANL's HPC Division, put the lab's interest in terms of elasticity when the project launched in June: an open, user-space metadata service that could run as an ephemeral service and be resized on the fly, according to the launch release. That release, dated June 3, 2026, said the architecture scales from a single server to more than 1,000 metadata servers and that Lattice was launched under the Linux Foundation. The project site describes the launch as a collaboration with the Linux Foundation, while the code itself sits in PEAK:AIO's own GitHub organization.
The licensing adds a wrinkle. The code is MIT-licensed except for one file, a shim that links to RonDB's NDB headers and is therefore GPL-2.0-or-later, per LICENSING.md. The same file lists modules that are absent from the public tree and available only in a proprietary enterprise build, including rebalancing and tiering, a Prometheus metrics endpoint, a stripe-map layout cache, LAYOUTCOMMIT coalescing, background garbage collection and pre-allocation on the data servers, weighted placement, and quotas. The community edition ships no-op stubs for these and, in the project's words, provides the full pNFS protocol surface, with the missing pieces being performance and operational features. At launch PEAK:AIO said it would also offer PEAK:AIO pNFS, a commercially supported superset of Lattice. Lattice is an open-core project, then, and NetApp's release says nothing about what happens to the MIT community edition or its outside contributors after close.
The performance record falls into three tiers.
NetApp's own release contains no measurements. Its claim that the architecture is intended to support trillions of files and multi-exabyte deployments is a statement of design intent.
PEAK:AIO and LANL published bandwidth figures at the June launch. According to the launch release, which Blocks & Files also reported, standard Linux NFS configurations on existing production hardware at Los Alamos delivered 3 to 7 GB/s while Lattice reached 40 GB/s on the same servers, and testing during the collaboration showed gains from 70 GB/s to 400 GB/s. The release also cites up to a 10x improvement on the mdtest metadata benchmark and more than 300% on metadata-heavy work at an unnamed "Tier 1 technical university." It states a baseline for two of the four figures: standard Linux NFS configurations on the same servers for the 40 GB/s result, and the Linux kernel NFS server for the mdtest result. It provides no starting configuration for the 70-to-400 GB/s figure and describes the university comparison only in terms of conventional approaches. The release names no other scale-out metadata design for comparison.
None of the sources checked gives client counts, file sizes, I/O patterns, network configuration, or data-server counts for these runs. The storage community already expects that kind of disclosure elsewhere; the IO500 committee recently moved two SCNet submissions from its Production lists to its Research lists, citing limited architectural detail and limited general availability of the file system.
The third tier, the developers' own lab notes in the repository, is the most detailed and the least publicized. A performance design document committed on August 7, 2026, records results from a three-MDS cluster backed by two RonDB data nodes, running 16-rank mdtest with 200 files per rank in a single iteration. Single-directory creates ran at 2,883 per second and 16-directory creates at 2,048 per second. With a cold cache, end-to-end creates ran at 408 per second and removes at 313.6 per second, against 77,326 stats and 18,553 reads per second. The document attributes nearly all of the mutation cost to one RonDB commit of about 0.78 ms, says creates and removes run ten to a hundred times slower than reads and stats on the same cluster, and says it does not yet have a matched baseline from a competing system. These are design-stage reference numbers published in the public repository. The document does not specify which build produced them, and its measurement plan relies on the Prometheus metrics endpoint, which the licensing file lists as an enterprise-only module. No result identified as coming from the enterprise edition appears in the sources SCN reviewed.
The same repository carries the developers' own conformance results. A conformance report on a three-MDS cluster records 198 of 198 pynfs NFSv4.1 tests passing with delegations enabled and 459 of 461 nfstest_posix tests passing. In the pNFS layout batch, 28 of 35 tests passed, four were skipped and three failed, and the developers attribute those three failures to the test harness. The README says multi-MDS concurrency was validated on a live RonDB cluster with two MDS daemons, and lists hardening still to do, including persisting session, open, and lock state to RonDB and testing Kerberos and mTLS. A companion performance note, committed August 7 like the design document, records a known limit. A file-handle cache in the MDS holds 16 entries while the registry allows 256 data servers; the developers call this irrelevant at current deployment sizes but write that it must be revisited before any deployment grows past 16 data servers.
NetApp's release says the combined architecture is meant to "help reduce data-related GPU stalls." It gives no measurement, and no source reviewed for this article reports an application-throughput or GPU-utilization result with Lattice. PEAK:AIO's launch material cited a Cast AI finding that average GPU utilization across 23,000 Kubernetes clusters on public clouds is 5 percent and tied that to storage bottlenecks. The link to metadata is PEAK:AIO's framing, and the figure says nothing about what Lattice changes.
Lattice depends on NFSv4 referrals to route clients across metadata servers. ONTAP's procedure for enabling pNFS requires that NFS referrals be disabled first, as the two cannot be enabled simultaneously. That rule governs ONTAP's own NFS server, where ONTAP acts as the metadata server for a storage virtual machine. Whether it bears on Lattice depends on a design NetApp has not described. If Lattice's metadata servers sit in front of ONTAP systems that act as data servers, the setting may never come into play. If the metadata service runs inside ONTAP's NFS stack, the two would have to be reconciled. That is SCN's reading of the two documents. The release is also silent on whether the work would land first on AFX, which already separates storage controllers from capacity, or on conventional ONTAP systems.
On timing, the release is unusually explicit. Its statement of product direction says NetApp "makes no commitment and has no obligation to develop or deliver any products, services, integrations, or any related features," and that the release and timing of anything built on PEAK:AIO's technology remain at NetApp's sole discretion.
The release lists PEAK:AIO deployments at LANL, NHS AIDE, the Oxford Robotics Institute, Carnegie Mellon, the University of Liverpool, the University of Strathclyde's MediForge Hub and the Zoological Society of London. That list covers PEAK:AIO's platform as a whole, including its AI Data Server storage product, and does not say which sites run Lattice. Banerjee told CRN that PEAK:AIO technology is already in use at several national laboratories and HPC environments. The sources don't establish that Lattice itself runs in production anywhere; LANL's 40 GB/s result was measured on production hardware, which is a different claim.
The customer list is mostly British and heavily academic and medical, and where data sits is a design decision for sites like these. CSCS put a 100-petabyte NASA data replica beside its Alps supercomputer, which SCN attributed to data locality and operational continuity. Lattice's pitch to such sites rests on unmodified kernel clients and data servers plus an MIT license, and how much of that carries into a commercial ONTAP product is for NetApp to settle after close.
The PEAK:AIO announcement follows NetApp's acquisition of DataPelago, announced July 16, 2026, and of JetStream Software, a VMware disaster-recovery and migration company, announced August 6. StorageReview counts PEAK:AIO as NetApp's second AI-focused acquisition in about two months. The deals come as storage vendors reposition around AI. VAST Data describes itself as the software layer between GPUs and applications, and SCN read its $30 billion valuation as a bet on that position. VAST has since previewed DataEnclave, which packages confidential GPU computing for customer hardware and is due in the first quarter of 2027. Lattice points NetApp to a narrower problem: making the standard NFS client scale for metadata-heavy workloads, with scaling done on the server side.
LANL and PEAK:AIO are on the program at the SNIA Storage Developer Conference in Santa Clara, September 28 to 30. On September 28, Brian Atkinson of LANL and John Harechmak of PEAK:AIO are scheduled to present "pNFS Lattice: Decoupling Metadata, State and Control in Parallel Filesystems" at 5:10 p.m. Pacific, and Grider is scheduled to lead a birds-of-a-feather session on fully open-source parallel NFS with Lattice at 7:00 p.m. Those sessions could be where test conditions behind the June bandwidth figures, or any workload-level data, first appear. After that, the markers are the close itself, the regulatory approvals the release alludes to, and whether NetApp commits to maintaining the community edition.
The SCN Staff is a small AI editorial squad working under human direction. Each agent owns one job.
Scout does the research. It runs down primary sources and checks what's already been published, on SCN and everywhere else, before a story gets written. If a claim can't be traced back to a real document, Scout flags it.
Forge writes. It takes what Scout found and turns it into a draft, argument and sentences and all. Every SCN piece starts here, then gets sharpened.
Cipher handles search: the titles, descriptions, and keyphrase work that decides whether a good article ever gets found. Least glamorous job on the squad. Also one that matters more than it looks.
Pixel makes the visuals. Images, charts, the occasional diagram, all built to SCN's brand instead of pulled from a stock library. When something's easier to see than to read, it goes to Pixel.
Editorial judgment and the final call stay with the humans. So does the fact-checking.
