Message-ID: <CAL=UVf7zTcmd32jgQStXFWKGpUGXLPqX19uPx_Xzqm_k7QGj0Q@mail.gmail.com>
Date: Wed, 23 Jul 2025 11:30:07 -0700
From: Paul Lawrence <paullawrence@...gle.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, Bernd Schubert <bernd.schubert@...tmail.fm>
Subject: Re: [PATCH v1 0/2] RFC: Extend fuse-passthrough to directories

> FUSE_CREATE already returns two out args.
> How were you planning to extend it?

Excellent point. However, FUSE_CREATE (and FUSE_TMPFILE) already has
fuse_open_out as the second argument, so the backing_id can be passed
in there. Does that sound acceptable? I'll admit that at first this
seemed clunky to me, but the more I think about it, the more natural
it seems - create is really an open, so it follows that paradigm, and
the new paradigm is used only for FUSE_LOOKUP.

FUSE_READDIRPLUS is harder, it seems to me. We would need to break ABI
compatibility - I can't see any sane alternative. A clean way would be
to have a FUSE_READDIR_PASSTHROUGH opcode. This implies that there's a
flag FUSE_PASSTHROUGH_MASK covering all of this new functionality
which would also enable this new opcode. (It could, alternatively,
change the behavior of FUSE_READDIRPLUS but I suspect no one is going
to like that idea.)

Does this seem reasonable?

Thanks,
Paul




On Wed, Jul 23, 2025 at 9:53 AM Amir Goldstein <amir73il@...il.com> wrote:
>
> On Tue, Jul 22, 2025 at 11:13 PM Paul Lawrence <paullawrence@...gle.com> wrote:
> >
> > I spent a little time with these patches. I wrote my own to set the
> > backing file at lookup time by adding an optional second out struct.
>
> FUSE_CREATE already returns two out args.
> How were you planning to extend it?
>
> > Is there a reason we should not do this? It seems the most natural
> > solution.
> >
> > After a while, I began to wonder if what I was planning was actually
> > the same as your vision. I decided to jot down my thoughts to see if
> > you agree with them. Also I was confused as to why you were adding the
> > ability to set backing files to GETATTR.
>
> It is a demo. It demonstrates that passthrough can be set up sooner than
> open time. It was not my intention to keep it this way.
>
> > So here are my notes.
> >
> > Design of fuse passthrough for all operations
> >
> > Goal:
> >
> > When a fuse filesystem implements a stacking filesystem over an
> > underlying file system, and a significant fraction of the calls will
> > simply be passed to the underlying file system, provide a mechanism to
> > pass those calls through without going to user space. This is
> > primarily to enhance performance, though it might simplify the daemon
> > somewhat too.
> >
> > Current state:
> >
> > Currently passthrough allows a backing file to be set at file open
> > time. If a backing file is set, all read/write operations will be
> > forwarded to the backing file.
> >
> > Design:
> >
> > Add ability to set backing file on the found inode in response to a
> > positive lookup. This file might be opened with O_PATH for performance
> > reasons. The lookup api would be modified to have an optional second
> > out struct that contains the backing file id. Note that we will use
> > the backing file ioctl to create this id to remove any security
> > concerns.
> >
> > The ioctl will also take a 64-bit integer to define which operations
> > will be passed through, the operations mask. This will have one bit
> > for each of the existing FUSE_OPERATIONS, at least the ones that act
> > on inodes/files.
> >
> > Then when fuse fs is considering calling out to the daemon with an
> > opcode, fuse fs will check if the inode has a backing file and mask.
> > If it does, and the specific opcode bit is set, fuse fs will instead
> > call out to a kernel function in backing.c that can perform that
> > operation on the backing file correctly.
> >
> > Details:
> >
> > Question: Will it be possible to change the mask/backing file after
> > the initial setting? My feeling is that it might well be useful to be
> > able to set the mask, the file not so much. Situations would be (for
> > example) a caching file system that turns off read forwarding once the
> > whole file is downloaded.
> >
>
> Generally, enabling passthrough from a point in time until the end of
> inode lifetime is easier than turning it off, but also there are many
> dependencies between passthrough ops and inode state so it will
> require a lot of care to enable *some* operations mid inode lifetime.
>
> > FUSE_OPEN will, if the backing file has been set, reopen it as a file
> > (not a path) if needed. This is whether or not FUSE_OPEN is passed
> > through.
> >
> > If FUSE_OPEN is passed through, user space will not get the chance to
> > assign a file handle ID to the opened file. It will still be possible
> > to pass FUSE_READ etc to the daemon - the daemon will still have the
> > node id and be able to read data based on that.
> >
>
> Not sure I understand what you mean, but we do support per file opt-out of
> passthrough with FOPEN_DIRECT_IO even when the inode is already
> set up for passthrough.
>
> > FUSE_LOOKUP can return a 0 node id, but only if *all* operations on
> > that node as marked as passthrough.
>
> Not sure why this is but I will be open to understanding.
> Will need an elaborate design of the inode lifetime in this case.
>
> >
> > Suggestion: During FUSE_LOOKUP, if FUSE_GETATTR is set in the mask,
> > ignore the passed in attributes and read them from the backing file.
>
> My patches already implement that when GETATTR is in the mask.
>
> >
> > Random, non-exhastive list of considerations:
> >
> > FUSE_FORGET can only be marked passthrough if the node id is 0.
> >
> > FUSE_CREATE returns a new node id and file handle. It would need the
> > ability to set backing files.
> >
> > If FUSE_LOOKUP is marked for passthrough, then looked up inodes will
> > be prepopulated with a backing O_PATH file and a mask will all bits
> > set.
> >
> > FUSE_RENAME takes two nodes and names, and moves one to the other. If
> > one is passthrough and one is not, there is no obvious way of
> > performing a rename. Either fall back to copy/delete or return EXDEV
>
> Good question.
>
> My patches were meant to provide you the basic infrastructure to enter
> this playground and show that you do not need backing dentry/inode
> beyond what is already available.
>
> I hope this is enough for you to start experimenting and sending RFC patches
> with design doc!
>
> Thanks,
> Amir.

Powered by blists - more mailing lists