From: John Groves <[email protected]> This patch series introduces famfs as a standalone file system, as a pivot back from fuse/libfuse, for which the porting effort took close to a year, but then the review effort started with almost a yearlong delay, and then got messy :D [3].
However, after years of maintaining famfs in both forms (standalone and fuse - the famfs user space works with both) I think famfs makes more sense as a standalone file system - and some influential maintainers have privately expressed that opinion to me. The most important thing to know about famfs is that it CANNOT be used as a general purpose file system. It is for enabling file-based byte-level access (including direct mmap) to very large (e.g. 100TB) shared/disaggregated memory appliances - which have become available during this long process, and which are in need of Linux support. So famfs cannot be used by anybody who doesn't know why they need it; Making famfs standalone means it can't affect users who don't use it. And my super- mega-corp employer (Micron), as well as other memory companies, need it. We do not intend to abandon it, but imagine if we did: fs/famfs/ should be removed if the memory companies can't be bothered to maintain it. This code base has been in active CI and used globally by early adopters and testers of disaggregated memory. I believe it is solid. History (skip if you lived it like I did :D) Famfs was introduced at LPC 2023 and LSFMM 2024 [1] as a standalone file system. The fuse odyssey started at LSFMM 24, but I think it's time to bring that to a close. The first fuse/libfuse patches came out in April 2025 [2] - adding a substantial amount of complexity to the famfs user space, and controversial complexity to fuse [3]. The fuse community was uncomfortable with the new metadata and fuse message formats that famfs needs, going so far as to suggest that famfs use a BPF program as a vma fault handler [3] to avoid the need to pass famfs file metadata via fuse messages - an idea which, to my relief, was definitively shot down at LSFMM 2026 [4]. In that session, I was preparing to make the pivot-to-standalone argument, and there were others in the room who support that - but Miklos stated that he was not opposed to merging famfs as it stands [4], leading me to back off of the standalone pivot at the time. However, 1) that is not how the recent patch discussions have been going [5], and 2) I have (not solely on that basis) come to the conclusion that famfs makes more sense as a standalone entity. In v11 [5] I dropped the controversial famfs interleaved extent (exploding fmaps from well under a page to megabytes), and there is still a push for adding an intermediate virtual backing dev layer that famfs does not need and can't really live with. I could go on... My argument Can we make famfs work in fuse? Yes, if we can agree some things that have been quite challenging to agree on. Should we? I think not. I think famfs adds complexity to fuse that will not likely see constructive re-use. And I think fuse makes famfs worse - significantly more complex, less adaptable to change, and less performant. And famfs files are memory - access needs to run at memory speeds! In short the risks out-weigh the benefits. About this patch series I've called it V12 for recent continuity; there was a V1 and a V2 standalone in 2024, and then V1-V11 were fuse (call this selective consistency). Famfs depends on the 'fsdev' dax mode which landed in 7.1 - it will only run with an fsdev-mode (aka famfs-mode) daxdev as its backing device(s). Patch 01 is a fix to the fsdev driver that is needed by the rest of the series. Famfs Overview Famfs exposes sharable disaggregated memory as a file system. Famfs consumes shared memory from [usually shared memory] dax devices, and provides memory-mappable files that map directly to the memory - no page cache involvement. Famfs differs from conventional file systems in fs-dax mode, in that it handles in-memory metadata in a sharable way (which begins with never caching dirty shared metadata). So a famfs file system can be mounted from multiple nodes, provided they have access to the memory. The key performance requirement is that famfs must resolve mapping faults with minimal overhead. This is achieved by fully caching the file-to-devdax metadata for all active files. Famfs remains the first fs-dax file system that is backed by devdax rather than pmem in fs-dax mode (hence the need for the new dax mode). The famfs user space can be found at [6] [1] https://lwn.net/Articles/983105/ (Famfs at LSFMM 2024) [2] https://lwn.net/Articles/1020170/ (Famfs at LSFMM 2025, with patch link) [3] https://lwn.net/Articles/1068686/ (LWN coverage of the patch thread) [4] https://lwn.net/Articles/1082687/ (Famfs at LSFMM 2026) [5] https://lore.kernel.org/linux-fsdevel/0100019f7d9fbe81-6cb16662-2522-47ea-a152-fab0ee3d9b35-000...@email.amazonses.com/#b [6] https://famfs.org John Groves (12): dax: replace exported dax_dev_get() with non-allocating dax_dev_find() famfs: Module operations, fs_context, and mount famfs: Add daxdev table and dax notify_failure support famfs: Introduce inode_operations and super_operations famfs: Introduce file_operations read/write famfs: Introduce mmap and VM fault handling famfs: MAP_CREATE ioctl and fmap ingest (ABI 44) famfs: iomap_begin and file-to-dax offset resolution famfs: Register secondary daxdevs by path (FAMFSIOC_DAXDEV_OPEN) famfs: Add runtime operation-permission (opts) framework famfs: Report device capacity via statfs so df works famfs: Add documentation Documentation/filesystems/famfs.rst | 142 +++ Documentation/filesystems/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 1 + MAINTAINERS | 8 + drivers/dax/fsdev.c | 19 + drivers/dax/super.c | 38 +- fs/Kconfig | 2 + fs/Makefile | 1 + fs/famfs/Kconfig | 11 + fs/famfs/Makefile | 5 + fs/famfs/famfs_file.c | 983 ++++++++++++++++++ fs/famfs/famfs_inode.c | 813 +++++++++++++++ fs/famfs/famfs_internal.h | 162 +++ fs/namei.c | 1 + fs/super.c | 7 + include/linux/dax.h | 7 +- include/linux/fs.h | 1 + include/uapi/linux/famfs_ioctl.h | 160 +++ include/uapi/linux/magic.h | 1 + 19 files changed, 2360 insertions(+), 3 deletions(-) create mode 100644 Documentation/filesystems/famfs.rst create mode 100644 fs/famfs/Kconfig create mode 100644 fs/famfs/Makefile create mode 100644 fs/famfs/famfs_file.c create mode 100644 fs/famfs/famfs_inode.c create mode 100644 fs/famfs/famfs_internal.h create mode 100644 include/uapi/linux/famfs_ioctl.h -- 2.53.0
