On Thu, Apr 16, 2026 at 01:53:27PM -0700, Dan Williams wrote: > > > On Thu, Apr 16, 2026, at 1:14 PM, Gregory Price wrote: > > On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote: > >> On Tue, Apr 14, 2026 at 5:10 PM John Groves <[email protected]> wrote: > >> > > >> > There is a FUSE_DAX_FMAP capability that the kernel may advertise or not > >> > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV > >> > commands. In the future, if we find a way to use BPF (or some other > >> > mechanism) to avoid needing those fuse messages, the kernel could be > >> > updated > >> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the > >> > famfs-specific > >> > code could be taken out of kernels that never advertise that capability. > >> > >> I’m not sure the capability bit can be used like that (though I am > >> hoping it can!). As I understand it, once the kernel advertises a > >> capability, it must continue supporting it in future kernels else > >> userspace programs that rely on it will break.
So don't break fuse servers. If you wanted to (say) get rid of GET_FMAP in favor of IOMAP_BEGIN, you could alter libfuse to translate a fuse server's ->get_fmap implementation into the equivalent ->iomap_begin, and eventually the kernel can stop making GET_FMAP calls to userspace. The trouble here is that I've also seen half a dozen projects vendoring libfuse so that's a nightmare that will have to be dealt with. But maybe that doesn't even matter, because... > > FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is > > not required to continue advertising FUSE_DAX_FMAP in perpetuity. > > > > Setting CONFIG_FUSE_DAX=n does not mean userland "is broken", this would > > only be the case if FUSE_DAX_FMAP was advertised but not actually > > supported. ...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... > > If DAX were removed from the kernel (unlikely, but stick with me) this > > would be equivalent to permanently changing CONFIG_FUSE_DAX to always > > off, and there would be no squabbles over whether that particular > > change broke userland (there would be much strife over removing dax). ...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: a) Using GET_FMAP as-is b) Uploading raw iomaps (HA) c) Uploading a single bpf program to make iomaps, exchanging fmap-style mapping data into a bpf map, and having the single bpf program walk through the map d) Uploading a custom bpf program per famfs file to make iomaps. No bpfmap required, but the setup and compilation are now much more complex Then we'll finally know which approach is the best, having broken the Gordian Knot of how to merge famfs and fuse-iomap. If we decide that (c) or (d) are actually better, then guess what? To get any of the iomap functionality, you have to set an inode flag, and that (FUSE_CAP_FAMFS && FUSE_CAP_IOMAP && FUSE_ATTR_IOMAP) is the signal for "don't call GET_FMAP". FUSE_CAP_FAMFS && (!FUSE_CAP_IOMAP || !FUSE_ATTR_IOMAP) means "call GET_FMAP". Yes, we burn a couple of fuse command values to find out, but that's all. (TBH I still dislike GET_DAXDEV, that really should just be another application of backing files, and the backing file id gets passed to GET_FMAP.) What do you all think of doing that? > > While not a deprecation method, this is what capability bits are > > designed for. Same as cpuid capability bits - just because the bit is > > there doesn't mean a processor is required to support it in perpetuity. > > > > They're only required to support it if the bit is turned on. > > > > Right, if the protocol on day one is "user space must ask which method > is available", then userspace can not be surprised when one option > disappears. So to give time for the bpf approach to mature the kernel > can do something like "famfs and bpf mapping support are available". > In some future kernel the famfs native option disappears after a > deprecation period. > > When folks ask 10 years from now why this ever supported optionality > the explanation is "oh because famfs enjoyed first mover advantage to > prove out fs semantics layered on dax devices", or "turns out there > are some cases where bpf is not fast enough but it still stops the > proliferation of more in kernel mapping implementations". Yes. We're not *capable* of determining the best mechanism unless we can start shipping these things to users to get their feedback. Only then can we iterate and make real improvements. > Something like FUSE_DAX_FMAP is always available but the backend to > that is optionally native vs bpf. ...or some other arrangement to make > it clear that native might be gone someday. --D
