Re: [PATCH V10 00/10] famfs: port into fuse

[Gregory Price]

On Mon, Apr 20, 2026 at 08:12:17PM -0700, Joanne Koong wrote:
> On Sun, Apr 19, 2026 at 5:27 PM Gregory Price <gourry@xxxxxxxxxx> 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