Most merge window entries tell you what landed. This one tells you what is coming. The NVDIMM and DAX patches merged for Linux 7.3, reported on Sunday, August twenty third, 2026, are largely fixes and refactoring in preparation for something that has not been submitted yet: FAMFS, the Fabric-Attached Memory File System that Micron engineer John Groves has been shepherding since early 2024. It has been through thirteen rounds of patch review, it is not aiming at the 7.3 merge window, and Micron is targeting upstream acceptance in 2026. It is also not a general purpose file system, which is the part worth understanding.
The short answer
The NVDIMM and DAX updates merged for Linux 7.3 are mostly fixes and refactoring that prepare the ground for Micron's FAMFS, a file system for fabric attached memory that has not been submitted upstream yet. FAMFS gives byte level, file based access to very large shared memory pools, and it lets multiple hosts mount the same file system from the same memory, which existing fs-dax file systems do not do. It is deliberately special purpose, and it matters mainly for CXL servers.
Reading a merge window summary and finding that the DAX subsystem spent a cycle on cleanup is not usually a story. It becomes one when you notice why the cleanup is happening.
Groundwork, not a feature
The NVDIMM and DAX activity in Linux 7.3 comes down to fixes, code refactoring and general improvements. The stated purpose is preparing for the introduction of FAMFS, which has not been submitted for inclusion.
That sequencing is normal for a file system that needs something from a shared subsystem. FAMFS is built on DAX, the mechanism that lets a mapping reach memory directly instead of going through the page cache, and DAX was written for persistent memory in single host machines. Pointing it at a memory pool that several hosts can see at once surfaces assumptions that were never wrong before, because nothing had asked those questions of it.
So the order of operations is: make DAX ready, then land the file system. Doing it the other way round produces a merge that reviewers cannot evaluate, because half the changes would be to code the file system does not own.
What fabric attached memory actually means
Strip away the acronyms and the shape is simple. A CXL 2.0 or 3.0 fabric can put a pool of DRAM behind a switch and expose it to multiple hosts, with coherency and connection handled by the protocol. Instead of memory belonging to one machine, you get memory belonging to a rack.
The sizes involved are what forces new software. FAMFS is designed around pools where a hundred terabytes or more is a normal figure, not a stretch case. At that scale, the old habit of copying a dataset to whichever host needs it stops being an inefficiency and starts being the entire cost of the job.
The gap is that raw shared memory has no vocabulary. It is an address range. It does not tell a second host where a dataset begins, how large it is, who owns it, or whether anyone is writing to it right now. Every project that reached for shared memory at this scale ended up building the same missing layer by hand, badly, and incompatibly with the next project.
FAMFS supplies that vocabulary using one everybody already speaks. Regions become files. Files have names, sizes and owners. An application maps one and works on the bytes.
The line that separates it from ext4
The claim that matters is narrower than it first appears, and it is worth being precise about.
Direct access to memory backed storage is not new. ext4 and XFS have supported fs-dax for years, and mapping a file into a process without the page cache in between is well trodden ground.
What is new is that FAMFS supports multiple hosts mounting the same file system from the same memory, which existing fs-dax file systems do not. Everything difficult about FAMFS follows from that single sentence. A conventional file system assumes one kernel is in charge of its metadata. Allocation, timestamps and directory structure are all safe to change because nobody else is changing them. Put two independent kernels in front of the same bytes and every one of those assumptions needs re examining.
That is also why the project is emphatic about being special purpose. Micron is not proposing FAMFS as a general purpose file system, and reads the requirement as file based, byte level access to very large shared and disaggregated memory. Narrow scope is what makes the hard problem tractable: you can say no to the features that would force full distributed coordination.
Kernel driver, and thirteen rounds
Two process details are worth noting because they say something about how seriously this is being taken.
The first is the FUSE question. Micron considered implementing FAMFS in user space through FUSE and concluded that a standalone kernel file system driver was the better approach, alongside a commitment to maintain it and a claim of demonstrated customer demand. The argument holds up better than the usual version of it. FAMFS exists to remove copies from the path between an application and a large memory pool, so putting a user space daemon in the fault handling path fights the purpose of the project.
The second is the review count. Thirteen rounds is a lot, and it reads two ways depending on temperament: a series struggling to convince anyone, or a series that reviewers keep engaging with. Given that the DAX subsystem is now being prepared specifically to receive it, the second reading is the one the evidence supports. Kernel maintainers do not refactor a subsystem for a patch set they intend to reject.
This is a quieter kind of file system news than the FailFS merge earlier in the same cycle, which landed complete and had a punchline. FAMFS has neither, and it will still matter more to anyone buying rack scale hardware.
Whether to care yet
If you do not have fabric attached memory, this changes nothing for you, now or after it merges. There is no version of FAMFS that improves a normal server, and it is not competing for the slot where you currently run ext4 or XFS.
If you are sizing CXL capable hardware for the next few years, it is worth tracking, because software support is usually the thing that decides whether a memory pooling deployment is a product or a research project. A file system interface that multiple hosts can mount is what turns a shared pool from a capability on a spec sheet into something an application team can actually target.
The realistic timeline is 2026 for upstream acceptance, on Micron's own aim, with distribution kernels following well behind that. The 7.3 cycle is not where it arrives. It is where the road gets paved.
Sources and further reading
- Linux 7.3 Makes Preparations Toward Upstreaming FAMFS File-System, Phoronix, August 23, 2026
- Micron Engineer Sends Out Linux Patches For New FAMFS File-System, Phoronix
- Famfs: a filesystem interface to shareable memory, LWN.net
- Introduce the famfs shared-memory file system, LWN.net
Frequently asked questions
What problem does FAMFS actually solve?
Naming and sharing a pool of memory that several machines can see at once. A CXL fabric can expose a large pool of DRAM to multiple hosts through a switch, but raw shared memory has no structure: no way to say this region holds that dataset, no way for a second host to find it, no permissions and no metadata. FAMFS puts a file system interface on top, so regions of shared memory become memory mappable dax files with names, sizes and ownership. Applications then reach the data with mmap and normal file semantics rather than inventing their own allocator and directory scheme, which is what everyone was doing before.
How is this different from existing fs-dax file systems like ext4 or XFS with DAX?
Sharing. ext4 and XFS both support fs-dax, which lets you map persistent memory directly into a process without going through the page cache, and that part is not new. What they do not support is multiple hosts mounting the same file system from the same memory at the same time. That is the specific capability FAMFS adds, and it is the reason it exists as a separate file system rather than as a patch to something established. The moment two independent machines share one memory pool, the assumptions a single host file system makes about who can change metadata stop holding.
Do I need CXL hardware to use it?
CXL is the obvious deployment target but FAMFS is not CXL specific in its design. A FAMFS instance can be created on a /dev/pmem device in fs-dax mode or on a /dev/dax device in devdax mode, so the underlying memory can come from more than one place. The reason CXL dominates the conversation is that a CXL 2.0 or 3.0 fabric is the practical way to get a pool of DRAM shared across hosts through a switch, with coherency and connection protocols already specified. Without something like that, shared fabric attached memory stays a lab exercise.
Why a kernel driver instead of FUSE?
Because the work happens on the memory mapping path, which is exactly where a user space file system pays the most. Micron evaluated the FUSE route and concluded a standalone kernel file system driver was the better approach, and committed to maintaining it, citing demonstrated customer demand. The case is easier to accept here than it usually is: the entire point of FAMFS is direct byte level access to memory with no copy in the way, so routing metadata operations and fault handling through a user space daemon works against the reason anyone wants it.
When can I expect to run this?
Not on 7.3. The file system itself was not submitted for the 7.3 merge window, and what landed is the DAX and NVDIMM groundwork that makes a later submission cleaner. Micron is aiming for upstream acceptance during 2026, and thirteen rounds of review suggests a series that reviewers take seriously rather than one that is being ignored. Even after it merges, this is not something you deploy on a normal server: it needs fabric attached memory to point at. Treat it as infrastructure that is arriving for a specific class of machine, not as a file system you will be choosing between ext4 and XFS.