Message-ID: <CAOQ4uxgqS0cK6ovwjMjSFndiFBUP1Z9ZXdAoCJayeo4W00nGLg@mail.gmail.com>
Date: Wed, 23 Jul 2025 18:53:21 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Paul Lawrence <paullawrence@...gle.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

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