On Tue, Apr 21, 2026 at 7:30 AM Gregory Price <[email protected]> wrote: > > 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).
I'm not sure if this addresses Christian's concerns or not, but the blob would reside within struct fuse_inode not struct inode. I definitely agree with him that this should not touch or add any infra outside fuse. I hadn't heard of bpf arenas until his comment. If the hashmap overhead is too high for famfs, having a custom in-arena hash table would be much faster I think, as it could be designed to require less pointer chasing and avoid other overhead in the bpf hashmap implementation, though now famfs would have to manage the data structure and complexity itself. Thanks, Joanne > > [1] > https://lore.kernel.org/linux-fsdevel/20260421-arsch-gelernt-e0b5bcd8a7ff@brauner/T/#m8fea90f5ed4a1b23bdc2563d978948b263b2030b > > ~Gregory
