On Tue, Oct 10, 2023 at 6:14 PM Amir Goldstein <amir73il@xxxxxxxxx> 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) > > > > 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. > I did not take into account that during create, backing file is setup before the kernel knows about the nodeid. I will keep the backing_id and will figure out how to avoid multi backing ids per inode. Thanks, Amir.
