On Fri, Apr 17, 2026 at 8:46 AM Gregory Price <[email protected]> wrote: > > On Thu, Apr 16, 2026 at 06:24:02PM -0700, Joanne Koong wrote: > > On Thu, Apr 16, 2026 at 1:14 PM Gregory Price <[email protected]> wrote: > > > > > > I worry that this discussion is going to turn towards implementing a > > > solution grounded in parsing arbitrary formats and how to store them, > > > and that is completely detached from why FAMFS went this route in the > > > first place. > > > > > > I question whether the actual issue here lies in the interface APPEARING > > > more general purpose than it actually is - and therefore inviting > > > attempts to over-genericize it. > > > > Would you mind clarifying this part? Are you saying that the interface > > and logic is *already* generic and usable for other dax-backed > > servers, just that everything is *named* famfs but it's not really > > famfs specific? > > Yes. > > If you just find/replace "famfs" with "dax_iomap", the structures > here don't really seem all *that* crazy specific - they're just > optimized for memory speeds instead of I/O. > > There is a circular nature to this - FAMFS figured it out first, in > what we think is a reasonably generic way, but we can't know for sure. > > John, Dan, and Darrick have all proposed reasonable ways to hedge > against the obvious fact the interface will not be perfect - which > incorporates your BPF proposal along with a reasonably straight forward > deprecation path that's not always possible in other arenas. > > All that while solving a real (and novel) problem. > > That's actually pretty damn cool. > > I would urge you to consider these proposals earnestly. >
Apart from your suggestion to replace s/famfs/dax_iomap/ the fact that this logic sits in fs/fuse/famfs.c (or fuse/dax_iomap.c) is the other big architecture issue. If this logic was to be placed in fs/iomap/ as Christoph suggested, I think the rest of the UAPI issues could be sorted out. In any case, considering the sheer amount of discussion on this thread I have scheduled a cross-track FS+MM+IO for Famfs and DAX iomap. I wasn't going to include Storage people at first, but since Christoph mentioned that stride/offset iomap could be useful for block iomap, I included them as well. Thanks, Amir.
