What Is FAMFS? Linux's New CXL Memory File System

You saw the headline about Linux kernel work preparing the ground for FAMFS and moved on, figuring it was another niche filesystem for people running exotic hardware. Fair guess, but wrong. FAMFS is Micron's answer to a problem that's about to hit anyone running large-scale databases or HPC clusters: how do you let multiple servers share the same pool of memory without rewriting every application that touches it?

The short version: FAMFS turns fabric-attached, CXL-connected memory into something that looks like a regular file but behaves like RAM. Multiple hosts can map that file into their address space and read or write it byte by byte, with no network calls, no serialization, and no waiting on a storage stack.

The Linux 7.3 kernel cycle didn't merge FAMFS itself. It merged the NVDIMM and DAX groundwork that FAMFS needs before Micron can submit the real filesystem code upstream. That distinction matters if you're trying to figure out when you can actually use this thing.

To understand why this is a bigger deal than "yet another filesystem," it helps to compare FAMFS against the two things it sits between: traditional shared storage and traditional shared memory.

FAMFS vs. Traditional Network Storage

Network filesystems like NFS or distributed storage like Ceph solve the multi-host access problem by moving data over a network protocol stack. Every read or write involves serialization, network round trips, and often a copy into and out of kernel buffers. That overhead is acceptable for cold data or bulk throughput, but it's murder for latency-sensitive workloads that need to touch memory thousands of times per second.

FAMFS skips almost all of that. Because it operates on CXL-attached memory, physically connected via the Compute Express Link interconnect rather than a traditional storage bus, the memory shows up directly in a host's physical address space. Combine that with DAX, the Direct Access mechanism in Linux that lets applications memory-map persistent memory devices without going through the page cache, and you get memory-mapped files where the "file" is really just a named region of shared physical memory. We cover related ground in see also: cifs/smb3 kernel maintainer steve french steps down.

There's no read() or write() syscall overhead in the hot path once the mapping exists. Applications treat it as memory because it is memory.

The tradeoff is scope. Network storage can span racks, datacenters, and continents, but CXL fabric topology bounds FAMFS: the hosts sharing a FAMFS instance need to attach to the same memory pool through a CXL switch or similar fabric hardware. It's a rack-scale or pod-scale technology, not a wide-area one.

FAMFS vs. Conventional Shared Memory (NUMA and RDMA)

Linux already has ways to share memory across boundaries. NUMA lets a single machine's CPUs access memory attached to other CPU sockets, and RDMA lets one server read another server's memory over InfiniBand or RoCE without involving the remote CPU. Both are mature, both are fast, and both carry real limitations that FAMFS works around.

NUMA sharing stops at the edge of a single physical machine. You can't NUMA your way into memory sitting in a different chassis. RDMA solves the cross-machine problem, but it requires developers to write the application against RDMA verbs or a library built on top of them, and it still involves a request-response model rather than transparent load and store instructions.

FAMFS aims for something closer to true shared memory across independent physical hosts. CXL fabric hardware exposes memory pools that sit outside any single host's CPU complex to multiple hosts simultaneously, and DAX maps that memory directly into a process's virtual address space. That means an application on Host A and an application on Host B can, in principle, address the same physical memory using ordinary load and store instructions.

No RDMA verbs, no explicit message passing. That's a meaningfully different programming model, and it's why database and HPC teams are watching this closely rather than shrugging it off as another mount option.

Why It Needs NVDIMM and DAX Plumbing First

This is the part that explains why the Linux 7.3 cycle looks like a lot of preparatory work rather than a finished feature. FAMFS doesn't invent a new memory-access mechanism from scratch. It leans heavily on infrastructure Linux already built for non-volatile DIMMs and persistent memory devices, namely the DAX layer and the NVDIMM subsystem's handling of device-mapped memory regions.

Kernel developers built that existing code around a specific mental model: one host, one set of persistent memory devices, files that map directly onto physical media. FAMFS needs to stretch that model to cover memory devices that live on a shared fabric and that more than one host accesses concurrently. That requires changes to how the kernel tracks device ownership, how it handles coherency and access permissions across hosts, and how DAX mappings interact with memory that no single kernel instance owns exclusively. This pairs well with go deeper on eevdf vs cfs: what really changed in linux scheduling.

Much of the recent kernel work amounts to hardening those assumptions and adding the hooks Micron's out-of-tree FAMFS code will eventually need. It's unglamorous work, mostly invisible to end users, but it's also the reason FAMFS hasn't just dropped into the kernel as a working feature yet. Upstreaming a filesystem that fundamentally changes what "a file" can mean takes longer than upstreaming a filesystem that just organizes bytes on a disk differently.

Who Actually Benefits From This

It's worth being honest about scope here, because FAMFS is not going to matter to most Linux users, including most system administrators running typical web and application servers. If you're managing a fleet of containers on commodity hardware, this changes nothing for you in the near term.

The real audience is narrower and more specific. In-memory database vendors get a way to build larger datasets than a single server's DRAM can hold, without paying the latency tax of a distributed cache layer. HPC shops running simulation workloads that need shared state across many compute nodes get a lower-latency alternative to message-passing libraries for certain data-sharing patterns.

Also read: context: why gnome extensions break after every shell update

Infrastructure teams building disaggregated memory pools benefit too. Where operators provision and reassign memory capacity across a fleet of servers independently of CPU allocation, FAMFS offers a filesystem abstraction that makes that pooled memory usable by ordinary applications instead of requiring custom drivers.

Micron's interest here isn't charitable. Memory vendors want CXL memory expansion and pooling to become a real market, and a usable, upstream-friendly software interface removes one of the big adoption barriers. Right now, using disaggregated CXL memory well requires either custom kernel patches or application-level rewrites, and neither approach scales to a broad customer base.

If you're running general-purpose Linux servers, treat FAMFS as something to watch, not something to plan around yet. It's not in Debian, Fedora, or Ubuntu's kernels, and it won't be until it clears upstream review, which hasn't started in earnest.

If you're building or evaluating disaggregated memory infrastructure, in-memory database clusters, or CXL-based HPC systems, keep tracking this closely. The DAX and NVDIMM groundwork landing now is the leading indicator that Micron's actual filesystem submission isn't far behind.