On 26/01/20 09:12AM, Alireza Sanaee wrote: > On Sun, 18 Jan 2026 22:29:18 +0000 > John Groves <[email protected]> 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/[email protected]/ > > [2] https://lore.kernel.org/linux-cxl/[email protected]/ > > [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/[email protected]/ > > (V2) > > [7] > > https://lore.kernel.org/linux-fsdevel/[email protected]/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
