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. > (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
