AI storage metadata, the bookkeeping that tells a system where every file lives and who may touch it, is what NetApp says it wants to fix by buying PEAK:AIO. The company announced on Friday, September 25, its intent to acquire the Manchester-based software maker, whose storage runs from a single server up to exabyte scale […]
AI storage metadata, the bookkeeping that tells a system where every file lives and who may touch it, is what NetApp says it wants to fix by buying PEAK:AIO. The company announced on Friday, September 25, its intent to acquire the Manchester-based software maker, whose storage runs from a single server up to exabyte scale on standard hardware. No price was disclosed, and the deal is subject to customary closing conditions and regulatory approvals.
The pairing is more specific than the usual “AI infrastructure” acquisition. NetApp’s framing is that shared storage has to scale alongside GPU clusters, and that the part which strains first is not raw bandwidth. It is the metadata service that handles opens, listings, permission checks and lookups across trillions of files.
What follows explains why metadata becomes the choke point, what PEAK:AIO has built, how its open-source pNFS Lattice design works, what NetApp says it will do with the technology, and what remains unknown. Facts come from NetApp’s press release and StorageReview’s same-day analysis. Where we are inferring, we say so.
The Data Path and the Metadata Path
Picture a library. The shelves hold the books, and the catalog says which shelf holds which. A reader fetching one enormous volume cares how fast the shelf can hand it over. A reader pulling ten million pamphlets cares about the catalog.
Storage systems split the same way. The data path moves bytes and is measured in gigabytes per second. The metadata path handles operations such as opening a file, reading its attributes, listing a directory, checking permissions and recording changes, and is measured in operations per second. Large sequential reads punish the first path. Millions of small files punish the second.
AI pipelines lean on both. Training jobs enumerate huge datasets and read many small samples, and checkpointing produces bursts of writes that hit directories and attributes all at once. When the metadata service falls behind, accelerators sit idle. That is why NetApp’s release talks about reducing data-related GPU stalls rather than simply adding bandwidth.
A Back-of-the-Envelope Look at the Problem
A purely illustrative example shows the scale. Suppose a dataset holds one billion small files and a metadata service sustains 100,000 operations per second. Enumerating that dataset once, at one operation per file, takes 10,000 seconds, nearly three hours, before a single byte of training data moves. Triple the files or halve the service rate and the wait grows in proportion.
Those numbers are hypothetical, not measurements from any vendor. The point is the shape of the curve. Adding disks raises capacity and throughput but does nothing for a single metadata server that has become the limit. The fix is a metadata layer that can be spread across many machines.
What PEAK:AIO Builds
According to NetApp’s release, PEAK:AIO makes software-defined AI storage that scales from one server to exabytes on industry-standard hardware. Its listed strengths are metadata innovation that extends metadata scale, a global namespace, and parallel NFS access for massively parallel workloads. The technology originated in collaborations with Los Alamos National Laboratory and Carnegie Mellon University, and the release names those institutions and the Oxford Robotics Institute among existing deployments.
The release does not describe a GPU-specific product. Its framing is shared storage that grows with the cluster beside it.
Inside pNFS Lattice
Parallel NFS, or pNFS, lets a client ask a metadata server where a file’s data lives and then talk to data servers directly and in parallel. The metadata server stays off the data path. A layout type called Flex Files allows those data servers to be ordinary NFS servers.
StorageReview describes pNFS Lattice as an open-source, scale-out metadata server for NFSv4.2 and pNFS Flex Files, developed with Los Alamos and Carnegie Mellon and released with Linux Foundation support. The design splits metadata authority, protocol coordination and data placement into separate layers. Several userspace metadata server daemons share a RonDB metadata store. Clients reach the right daemon through standard NFSv4 referrals, and the data servers are unpatched Linux knfsd instances serving the Flex Files layout over TCP or RDMA.
The code is MIT-licensed on GitHub, apart from one GPL-2.0 file that links to RonDB. PEAK:AIO itself calls Lattice an early release for research, development and testing and does not recommend it for production.
Two features stand out. Because the protocol is standard NFS, the design asks little of the data servers and clients that already speak it. And because several metadata daemons share one store, metadata capacity can grow by adding daemons instead of adding disks, which is the separation the problem above calls for.
What NetApp Says It Will Do
The release lays out a product direction in four parts: add PEAK:AIO’s metadata services and parallel namespace to NetApp’s ONTAP-based architecture, create an upgrade path for existing ONTAP customers, separate metadata from data so metadata services scale independently, and aim at trillions of files and multi-exabyte deployments while keeping ONTAP’s resilience, security and operational simplicity. A disclaimer notes that NetApp makes no commitment to deliver any specific feature or integration, and that timing is at its discretion.
NetApp CEO George Kurian framed the deal as AI clouds needing high-performance shared storage that scales with GPU clusters yet stays resilient and simple to run. PEAK:AIO founder and CTO Mark Klarzynski said joining NetApp pairs his company’s innovation culture with NetApp’s reach and customer trust. StorageReview suggests independent metadata scaling, a global namespace and parallel NFS would fit NetApp’s AFX distributed design. That is the outlet’s inference, not a NetApp statement.
What Nobody Has Said Yet
- Terms and timing. There is no price, no closing date and no roadmap, and NetApp has not said where the technology lands first.
- Open-source future. It is unclear whether NetApp will keep developing Lattice in the open.
- Metadata benchmarks. None have been published. StorageReview notes that the performance figures circulating, including 160 GB/s over NVMe-oF RDMA and 300 GB/s locally on a Dell PowerEdge R7725xd, measure data-path throughput, not metadata scaling.
- Market fit. PEAK:AIO has served research institutions and hospitals that cannot justify large arrays behind a single GPU server. How that customer base fares inside a larger company is unaddressed.
How to Read the Deal If You Run AI Storage
- Measure metadata separately. Benchmarks such as mdtest, part of the IO500 suite, report metadata operations per second. Run them against your real file counts.
- Ask vendors for metadata numbers. Throughput figures alone will not show whether a design survives a billion small files.
- Check client support. pNFS depends on your kernel and NFS client versions, so test before you plan around it.
- Watch the namespace. A global namespace across sites changes data placement, access control and cost, and deserves its own review.
- Keep the hardware in view. For the media underneath, our look at PCIe 6.0 SSDs in data centers covers where flash is heading.
Why NFS, Again?
NFS is among the oldest protocols in the data center, which makes its place in AI storage look odd at first. The appeal is practical. Standard NFS clients ship with Linux, so a design built on them avoids the agents and special client software that some parallel file systems require. Parallel NFS arrived as part of the NFSv4.1 revision to remove the old bottleneck of one server handling every data transfer, and the Flex Files layout extends that idea to commodity data servers. That history is general background, not drawn from the deal coverage.
The trade-off is control. A purpose-built client can tune its behavior for one workload in ways a standard client cannot, and no benchmark in the material we reviewed compares the two approaches. What the PEAK:AIO design offers instead is operational familiarity: administrators, security tools and kernels already understand NFS.
The Open-Source Question
Lattice’s MIT license, apart from the single GPL-2.0 file that links to RonDB, means anyone can read, use and fork the code. For customers, that cuts two ways. If NetApp narrows its investment, a community or a rival could carry the code forward. But an early release that its authors do not recommend for production is not something a buyer can lean on today, and NetApp has not said whether open development will continue after the deal closes. Until it does, treat Lattice as a design to study, not a product to deploy.
The Bottom Line
NetApp’s announcement on September 25 tells you more about where AI storage problems are heading than about any product you can buy today. The company is paying to acquire metadata scaling, which suggests that serving trillions of files has become a design problem in its own right and not an afterthought to raw throughput. The technology is early, the price is unknown and the integration plan carries an explicit no-commitment disclaimer.
For teams running GPU clusters, the practical lesson is cheap to act on. Measure metadata operations separately from bandwidth, ask suppliers for numbers that cover both, and check whether your clients and kernels can use parallel NFS. Those steps pay off whether or not this particular deal closes the way NetApp describes.
Sources and Verification Notes
Deal terms are undisclosed. The pNFS explanation, the mdtest and IO500 reference and the worked example are general background, not drawn from the sources, and we did not review PEAK:AIO’s own documentation.
