On Fri, 2026-08-21 at 17:21 -0700, Darrick J. Wong wrote: > 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. >
Agreed -- this is exactly my take as well. While I sent a R-b for John's standalone work, I've no issue if the better path forward is deemed to be FUSE. I'd just like to see this come to some sort of resolution. Cheers, -- Jeff Layton <[email protected]>
