Message-ID: <CAL=UVf5W9eJF4FL6aRG4e1VoFWg8jj4X4af=j-OGdU=QxmPuwA@mail.gmail.com>
Date: Tue, 22 Jul 2025 14:13:12 -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

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.
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. 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.

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.

FUSE_LOOKUP can return a 0 node id, but only if *all* operations on
that node as marked as passthrough.

Suggestion: During FUSE_LOOKUP, if FUSE_GETATTR is set in the mask,
ignore the passed in attributes and read them from the backing file.

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

Powered by blists - more mailing lists