On Thu, 23 Jul 2026 at 02:32, John Groves <[email protected]> wrote: > I will make this high-level comment: After reading Amir's initial reply, I > concluded that the requested changes push famfs past the breaking point, > and therefore the only way to keep famfs suitable for its intended usage is > to pivot back to standalone. I do think that may be best all-around for fuse, > famfs and Linux. I don't see any way famfs makes fuse better - it's a very > specialized pattern that doesn't fit in a passthrough-filesystem or > block-filesystem shaped hole. And I don't think it can comply with the > "nothing famfs-specific in GET_FMAP" objective.
I can say with confidence that there is nothing famfs specific in GET_FMAP that is actually being used. There are some unused and redundant fields in your struct that can be removed now, and we can leave space for future extension in the extent format. Adding code for unused features makes little to no sense but can add significant burden. Allowing extensibility instead should be a much better choice. As Joanne mentioned, adding extent mapping to fuse would be a generically useful feature. It's been on my mental todo list for 10-15 years. Sure, we can do that without famfs, so... > If famfs is standalone, it can only ever affect customers who use it, and it > cannot be used as a general purpose file system. When famfs is in fuse, it's > mashed up with code for hundreds or thousands of other use cases. That's not > a win from a risk management standpoint, and it doesn't make famfs better - > certainly not in any way that would mitigate adding a lot of state / > complexity / baggage to famfs. The risk of standalone is abandonment. That's a call for the VFS maintainers, I'm not going to stand in the way. Thanks, Miklos
