On Fri, Aug 21, 2026 at 09:39:26PM +0200, Miklos Szeredi wrote: > On Fri, 21 Aug 2026 at 13:40, David Hildenbrand (Arm) <[email protected]> > wrote: > > > (a) Whether a fuse-based approach is feasible. > > > > Are there any major blockers remaining? > > No. > > > (b) Whether a fuse-based approach is inefficient. > > > > Are there scenarios remaining where performance or metadata overhead > > would > > be bad without an easy way to improve the situation? > > Lookups can be cached, extent mappings can also be cached. After the > inode is in cache and the mapping is set up zero requests are needed > for open/mmap/read/write/close. > > > (c) Whether a fuse-based approach is a bad conceptual fit. > > > > Will fuse have to carry a lot of famfs special sauce that cannot > > really be used elsewhere / generalized? > > None. > > But "can" and "will" are not the same. The striping code might not be > very useful outside of famfs. > > > (d) Whether a fuse-based approach is too invasive. > > > > Will fuse extensions to support famfs actually make it harder to > > maintain or > > slower on some paths? > > No. > > > (e) Whether a fuse-based approach will make famfs harder to extend. > > > > Is there known follow-up work that will be hard/impossible to model in > > fuse? > > It would actually make famfs much easier to extend, since the > directory structure, metadata, etc. is now controllable within the > userspace server. > > > (f) Whether a fuse-based approach will reduce maintenance effor > > > > Will maintaining fuse extensions possibly be harder than maintaining > > standalone famfs? > > Testing is a key point. Famfs needs special hardware or emulation, so > it's not straightforward to test. This could be solved by adding a > "dummy" mode to famfs server that exercises the same fuse API, but > instead of special hardware would just use plain memory. > > > (g) Whether a fuse-based approach would make famfs more complex. > > > > Will the shift to user space result in a significantly more complicated > > overall solution that must be maintained? > > The server would be somewhat more complex, since it's now implementing > things like pathname lookup, etc. But the other stuff (managing file > maps) should be very similar. > > > (h) Who would help drive the fuse approach? > > > > Fuse people seem to be willing to help, but I expect that there must be > > a > > close cooperation with John to make this fly. I don't expect that John > > himself can easily (or understandably wants to :) ) do the heavy fuse > > lifting. > > Yes, this is where previous efforts seem to have gone off the rails. > So I agree to take responsibility for implementing the kernel side and > help with the server side on the condition that John has trust in > this. I'm not promising -7.4, but can at least try. > > Without John's trust I'm not taking this on.
Whatever path you and John decide on, I would very much like to see the question of Which famfs driver do we merge? to be resolved for 7.4. --D > > (i) Who would maintain any famfs fuse extensions and own any bugs? > > > > famfs will possibly depend on fuse extensions that might initially only > > be > > used by famfs. Would the fuse maintainers just naturally deal with that? > > I can take responsibility for the fuse kernel bits. > > > (j) Whether a fuse-based approach has an end in sight. > > > > famfs goes back .... quite a long time. It would be nice to close that > > chapter :) > > > > Is there an end in sight, or could we end up in the same situation in > > 6m/1y/ > > ... > > > > IOW, is there a way to agree on an MVP that won't require a lot of > > further > > re-planning and changes to a fuse-based design? > > I already sent patches to implement the dax dev mapping, and the > striping. We've discussed adding support for fixed backing ID, which > was something that John asked for. The only missing piece was adding > a protocol extension to set up simple extent mappings, which already > existed in the famfs_fuse patch, just needed to be renamed and unused > fields changed to "spare". > > We (Amir, Joanne, me) explained to John how this is exactly what's > needed to make famfs work. We've not seen an acceptance of that yet. > > From my PoV this would be extra work, but in the longer term would > expect to be less overall maintenance work and fuse would gain some > useful features in the process. > > Thanks, > Miklos
