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

[Christian Brauner]

On Fri, Apr 17, 2026 at 12:35:13PM -0700, Joanne Koong wrote:
> On Fri, Apr 17, 2026 at 1:04 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> > This is the first mail without annoying and pointless full quotes,
> > so chiming in here.  Sorry if I missed something important in all the
> > noise.
> >
> > On Tue, Apr 14, 2026 at 03:19:36PM +0200, Miklos Szeredi wrote:
> > > On Fri, 10 Apr 2026 at 21:44, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > >
> > > > Overall, my intention with bringing this up is just to make sure we're
> > > > at least aware of this alternative before anything is merged and
> > > > permanent. If Miklos and you think we should land this series, then
> > > > I'm on board with that.
> > >
> > > TBH, I'd prefer not to add the famfs specific mapping interface if not
> > > absolutely necessary.
> >
> > Yes,  fuse needing support for a specific file systems sounds like a
> > design mistake.
> >
> > >This was the main sticking point originally,
> > > but there seemed to be no better alternative.
> > >
> > > However with the bpf approach this would be gone, which is great.
> >
> > So what is this bpf magic actually trying to solve?
> 
> It is trying to avoid having famfs-specific implementation details
> hardcoded permanently into fuse's uapi and kernel code. I really like
> your suggestion of adding generic stride/offset multi-device support
> to fs/iomap. That is a much better solution than bpf.

If you go down the bpf route you will just have to use bpf hashmaps to
associate the blobs that you need with the relevant data structure and
then activate it from whatever hook you need. There's now very flexible
hashmap storage that you can autoresize - or you can use bpf arenas.
There's a ton of options that don't require modifying core structures.

IOW, I don't want dedicated bpf storage in struct inode. Not just
because bpf people consider dedicated blob storage in kernel structures
obsolete and recommend to use hashmaps - which is e.g., what I use for
another project of mine where I associate metadata with block devices -
but also because I very much disagree with bloating generic infra.