On Mon, Apr 20, 2026 at 08:12:17PM -0700, Joanne Koong wrote: > On Sun, Apr 19, 2026 at 5:27 PM Gregory Price <[email protected]> wrote: > > > > struct fuse_dax_fmap_ops { > > char name[FUSE_DAX_FMAP_OPS_NAME_LEN]; // 16 bytes > > int (*dax_fmap_parse)(struct fuse_dax_fmap_parse_ctx *ctx); > > Just a note for later, if the bpf approach gets pursued further: > instead of making this a dax specific ops, I think this needs to be > integrated interface-wise with Darrick's fuse-iomap work since he does > the same thing. I think dax_fmap_parse() could be renamed to something > like iomap_setup(), where userspace can use this to do any sort of > generic setup, whether that's mapping related or dax related or not. > In my mind, the dax vs non dax distinction is handled by the fuse > iomap plumbing that chooses which iomap entry points to call, but > beyond that, the callbacks and struct ops themselves should be > generic enough to be shared between the two. >
I think this is reasonable. I'm not a FUSE wizard either, but I would presume the iomap_setup() process would just essentially be John's existing GET_FMAP / GET_DAXDEV code bundled. GET_DAXDEV happens lazily to save him the round-trips to userland if the DAXDEVs have already been seen previously. I think your proposal does in fact save him further round trips, and it would probably solve the performance impact he saw from porting to FUSE. > > And otherwise, imap_begin() works exactly as Joanne proposed, but with > > in-kernel cached data instead of the bpfmap. > > > > const struct dax_simple_meta *meta = (const struct dax_simple_meta *) > > bpf_fuse_dax_resolve_get_meta(ctx, 0, sizeof(*meta)); > > another note for later, if the benchmarks prove promising and after > the LSF discussions we decide to go with this approach: imo we > could/should repurpose this into a generic > bpf_fuse_iomap_get_inode_meta() that returns a bounded pointer into > whatever opaque blob was cached on the inode during iomap_setup(), > where it'd be a generic kfunc serving both the dax and non-dax case > for any kind of mapping layout > Note that Christian Brauner just said he preferred not having dedicated bpf storage in struct inode [1]. sans BPF, is there value in such a metadata blob existing? If there was a generic format, then I suppose the blob storage would not be BPF specific, it would just overload it (simple union). [1] https://lore.kernel.org/linux-fsdevel/20260421-arsch-gelernt-e0b5bcd8a7ff@brauner/T/#m8fea90f5ed4a1b23bdc2563d978948b263b2030b ~Gregory
