On Tue, Oct 10, 2023 at 5:31 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Sun, 8 Oct 2023 at 19:53, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Ok, posted your original suggestion for opt-in to fake path: > > https://lore.kernel.org/linux-fsdevel/20231007084433.1417887-1-amir73il@xxxxxxxxx/ > > > > Now the problem is that on FUSE_DEV_IOC_BACKING_OPEN ioctl, > > the fake (fuse) path is not known. > > > > We can set the fake path on the first FOPEN_PASSTHROUGH response, > > but then the whole concept of a backing id that is not bound to a > > single file/inode > > becomes a bit fuzzy. > > > > One solution is to allocate a backing_file container per fuse file on > > FOPEN_PASSTHROUGH response. > > Right. How about the following idea: > > - mapping request is done with an O_PATH fd. > - fuse_open() always opens a backing file (just like overlayfs) > > The disadvantage is one more struct file (the third). The advantage > is that the server doesn't have to care about open flags, hence the > mapping can always be per-inode. > OK, this was pushed to the POC branches [2][3]. NOTE that in this version, backing ids are completely server managed. The passthrough_hp example keeps backing_id in the server's Inode object and closes the backing file when server's inode.nopen drops to 0. Even if OPEN/CREATE reply with backing_id failed to create/open the fuse inode, RELEASE should still be called with the server provided nodeid, so server should be able to close the backing file after a failed open/create. I am ready to post v14 patches, but since they depend on vfs and overlayfs changes queued for 6.7, and since fuse passthrough is not a likely candidate for 6.7, I thought I will wait with posting, because you must be busy preparing for 6.7(?). The remaining question about lsof-visibility of the backing files got me thinking and I wanted to consult with io_uring developers regarding using io_uring fixed files table for FUSE backing files [*]. [*] The term "FUSE backing files" is now VERY confusing since we have two types of "FUSE backing files", so we desperately need better names to describe those two types: 1. struct file, which is referred via backing_id in per FUSE sb map 2. struct backing_file, which is referred via fuse file ->private (just like overlayfs backing files) The concern is about the lsof-visibility of the first type, which the server can open as many as it wants without having any connection to number of fuse inodes and file objects in the kernel and server can close those fds in its process file table, making those open files invisible to users. This looks and sounds a lot like io_uring fixed files, especially considering that the server could even pick the backing_id itself. So why do we need to reinvent this wheel? Does io_uring expose the fixed files table via lsof or otherwise? Bernd, IIUC, your work on FUSE io_uring queue is only for kernel -> user requests. Is that correct? Is there also a plan to have a user -> kernel uring as well? I wouldn't mind if FUSE passthrough depended on FUSE io_uring queue, because essentially, I think that both features address problems from the same domain of FUSE performance issues. Do you agree? Am I over engineering this? Thanks, Amir. Changes from v14-rc1 to v14-rc2 [2]: - rebase on 6.6-rc6 (and overlayfs and vfs next branches) - open a backing_file per fuse_file with fuse file's path and flags - factor out common splice/mmap helpers from overlayfs - remove inode-bound (no backing id) backing file mode - use backing_id as input arg for close ioctl - remove auto-close mode Changes from v13 to v14-rc1 [1]: - rebase on 6.6-rc1 - factor out common read/write helpers from overlayfs - factor out ioctl helpers - per-file and per-inode backing file modes - optional auto close flag [1] https://github.com/amir73il/linux/commits/fuse-backing-fd-rc1 [2] https://github.com/amir73il/linux/commits/fuse-backing-fd-rc2 [3] https://github.com/amir73il/libfuse/commits/fuse-backing-fd
