On Mon, Aug 03, 2026 at 10:52:19AM +0200, Amir Goldstein wrote: > > 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. > > It does not work this way. > When vfs maintainers accept standalone famfs they accept the burden of > maintaining it whenever vfs internal APIs change even if the filesystem was > abandoned by the mega-corps. > That is the code of the push back for adding new filesystems. > Removing the fs and breaking deployed systems is not an option for the vfs > maintainers.
Sure it is. We removed EFS just last month, because we decided that it wasn't worth keeping any more. Just like we removed Itanium architecture support (and a number of other architectures before that). We've removed other filesystems in the past (xiafs, ext, surely a few others). Yes, there are burdens on others by accepting this filesystem -- but if it's a standalone VFS filesystem, those are felt by those who work on the VFS. If it's part of FUSE, then it's felt by those who work on FUSE. And we've already determined that those who work on FUSE are even more overburdened than those who work on the VFS. famfs does not seem to be a natural fit for FUSE. It has needs unlike any other Linux filesystem, and quite possibly unlike any other filesystem that is to come. Rearchitecting FUSE to make famfs fit seems like a very dodgy proposition to me.
