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) > I think it makes sense and it is in the direction that FUSE BPF took so that's good. > 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. I am fine with that. One more struct file per inode is not that big of an overhead and one backing file per fuse file is the same overhead as overlayfs. Does it mean that we can drop backing_id's and use the "inode bound" FUSE_BACKING_MAP_INODE mode to map the O_PATH fd to an inode, where the FUSE_DEV_IOC_BACKING_OPEN ioctl takes a nodeid as an input argument? Or do you still think that we need the backing_id, so we can map the same O_PATH fd to different inodes? To me, one O_PATH fd per inode without any backing_id seems like a simpler start. Thanks, Amir.
