Re: [post LSFMM summary] where is fuse going?

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/5/12 01:18, Amir Goldstein wrote:
> On Mon, May 11, 2026 at 5:12 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> Please let know what I missed.
>>
>> CO-MAINTAINER:  Position still open, though we formalized some
>> subsystem maintainership roles, sent MAINTAINERS patch.
>>
>> FAMFS: Let's try to find some common ground between the fuse-iomap api
>> and the famfs api.  I.e. add striping as a generic mapping method,
>> even though normal filesystems don't (currently) use it.  Using BPF is
>> a bad idea.
> 
> IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
> The simple nature of the maps, the fact that famfs maps are const and
> queried at file open time makes me think that famfs is much closer to
> PASSTHROUGH than it is to IOMAP (in its full capacity).
> 
> I think Joanne has mentioned that her customers have a use case for
> multi backing ids per passthrough file and I assume this would be a pretty
> simple map, so that sounds pretty darn close to famfs already.

I vaguely remembered that Joanne mentioned that mapping multiple
backing files into one FUSE inode at the end of session.

Is that the case you mentioned here? The requirement _might_ be
reasonable, but how does the entire page cache work for such cases?
Each vma can only point to exact one single real vm_file and rmap
totally relies on it.

Unless there are some more non-trivial core-MM enhancement (e.g. to
split into several vmas for each range), I don't think it's possible
for the current page cache infra. For DAX, it might be possible
since DAX has a seperate workflow.

Thanks,
Gao Xiang