On Thu, Apr 16, 2026 at 03:43:31PM -0700, Darrick J. Wong wrote: > ...the memory interleaving is a rather interesting quality of famfs. > There's no good way to express a formulaic meta-mapping in traditional > iomap parlance, and famfs needs that to interleave across memory > controllers/dimm boxen/whatever. Throwing individual iomaps at the > kernel is a very inefficient way to do that. So I don't think there's a > good reason to get rid of GET_FMAP at this time...
Why no? We can triviall make an iomap point to multiple backing devices and throw in a stride/offset. That would make btrfs striping (and non-degraded parity RAID reads) a lot more efficient. > ...however the strongest case (IMO) would be if (having merged famfs) we > then merge fuse-iomap after famfs. Then we extend the existing > fuse-iomap-bpf prototype to allow per-mount and per-inode iomap bpf ops. > That enables us to analyze thoroughly the performance characteristics of: Don't go there. I think that you two are comining up with two interfaces for roughly the same thing is a pretty clear indicator that this needs to be fully hashed out as a single interface first, and any kind of preliminary merging is just going to create problems.
