On 10/16/23 12:30, Amir Goldstein wrote:
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?
Right now I don't have support with the ring for user -> kernel
notifications yet. Though we will make heavily use of a distributed lock
manager (DLM) - that will need fast notifications and so better over a
ring. In principle I could also use the existing ring and take some
credits for the notifications, but it would make it harder to understand
what is going on when something goes wrong.
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?
The goal is definitely the same, just two different so far orthogonal ways.
I need to hurry up with the patch updates, got distracted by
atomic-open. direct-io and ddn internal work...
Thanks,
Bernd
