On Mon, 16 Oct 2023 at 12:30, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > 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(?). Dont' worry about that. > 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? I don't think so. > > 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? It's a good plan if it all fits together. I'm not all that familiar with io_uring to say for sure. Thanks, Miklos
