linux-kernel - Re: [PATCH BUNDLE v7] famfs: Fabric-Attached Memory File System

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0100019bdbf77d8b-fc329dba-dc0d-4233-9b6a-b45e3e271727-000000@email.amazonses.com>
Date: Tue, 20 Jan 2026 15:13:08 +0000
From: John Groves <john@...alactic.com>
To: Alireza Sanaee <alireza.sanaee@...wei.com>
Cc: John Groves <John@...ves.net>, 
	Miklos Szeredi <miklos@...redi.hu>, 
	Dan Williams <dan.j.williams@...el.com>, 
	Bernd Schubert <bschubert@....com>, 
	Alison Schofield <alison.schofield@...el.com>, 
	John Groves <jgroves@...ron.com>, 
	John Groves <jgroves@...tmail.com>, 
	Jonathan Corbet <corbet@....net>, 
	Vishal Verma <vishal.l.verma@...el.com>, 
	Dave Jiang <dave.jiang@...el.com>, 
	Matthew Wilcox <willy@...radead.org>, 
	Jan Kara <jack@...e.cz>, 
	Alexander Viro <viro@...iv.linux.org.uk>, 
	David Hildenbrand <david@...nel.org>, 
	Christian Brauner <brauner@...nel.org>, 
	Darrick J . Wong <djwong@...nel.org>, 
	Randy Dunlap <rdunlap@...radead.org>, 
	Jeff Layton <jlayton@...nel.org>, 
	Amir Goldstein <amir73il@...il.com>, 
	Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
	Stefan Hajnoczi <shajnocz@...hat.com>, 
	Joanne Koong <joannelkoong@...il.com>, 
	Josef Bacik <josef@...icpanda.com>, 
	Bagas Sanjaya <bagasdotme@...il.com>, 
	James Morse <james.morse@....com>, 
	Fuad Tabba <tabba@...gle.com>, 
	Sean Christopherson <seanjc@...gle.com>, 
	Shivank Garg <shivankg@....com>, 
	Ackerley Tng <ackerleytng@...gle.com>, 
	Gregory Price <gourry@...rry.net>, 
	Aravind Ramesh <arramesh@...ron.com>, 
	Ajay Joshi <ajayjoshi@...ron.com>, 
	venkataravis@...ron.com <venkataravis@...ron.com>, 
	linux-doc@...r.kernel.org <linux-doc@...r.kernel.org>, 
	linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>, 
	nvdimm@...ts.linux.dev <nvdimm@...ts.linux.dev>, 
	linux-cxl@...r.kernel.org <linux-cxl@...r.kernel.org>, 
	linux-fsdevel@...r.kernel.org <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH BUNDLE v7] famfs: Fabric-Attached Memory File System

On 26/01/20 09:12AM, Alireza Sanaee wrote:
> On Sun, 18 Jan 2026 22:29:18 +0000
> John Groves <john@...alactic.com> wrote:
> 
> Hi John,
> 
> I wonder if these new patches sent recently have been reflected on the github repo readme files. It seems it is not, is it?
> 

[ ... ]

> > 
> > References
> > ----------
> > [1] https://lore.kernel.org/linux-cxl/cover.1708709155.git.john@groves.net/
> > [2] https://lore.kernel.org/linux-cxl/cover.1714409084.git.john@groves.net/
> > [3] https://lwn.net/Articles/983105/ (LSFMM 2024)
> > [4] https://lwn.net/Articles/1020170/ (LSFMM 2025)
> > [5] https://famfs.org (famfs user space)
> > [6] https://lore.kernel.org/linux-cxl/20250703185032.46568-1-john@groves.net/ (V2)
> > [7] https://lore.kernel.org/linux-fsdevel/20260107153244.64703-1-john@groves.net/T/#m0000d8c00290f48c086b8b176c7525e410f8508c (related ndctl series)
> > --

Hi Ali,

[5] points to the main famfs user space repo; I haven't updated documentation
there yet. The master branch there works with this patch set, and also
remains compatible with famfs kernels back to 6.8 (both fuse and standalone),
but I recommend this latest version (which is the famfs-v7 tag in my kernel
repos).

Some people are still running standalone famfs, and for that I recommend the
famfs_dualv3 branch, which supports both fuse and standalone mounts in a
6.14 kernel. I don't currently plan to forward-port standalone famfs to
6.19, because fuse is the path forward.

We're working on a performance regression test suite now, but early
indications are the fuse version is equivalent performance to standalone -
except for open, which is slower due to the fuse kernel/server interaction.
Most of our use cases involve large data sets, so we think this is OK - but
there is an opportunity later optimization of open.

Hope this is helpful,
John