On Fri, Feb 10, 2023 at 7:52 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > Several fuse based filesystems pass file data from an underlying > filesystem without modification. The added value can come from > changed directory structure, changed metadata or the ability to > intercept I/O only in special cases. This pattern is very common, so > optimizing it could be very worthwhile. > > I'd like to discuss proposed solutions to enabling data passthrough. > There are several prototypes: > > - fuse2[1] (myself, very old) > - fuse-passthrough[2] (Alessio Balsini, more recent) > - fuse-bpf[3] (Daniel Rosenberg, new) > > The scope of fuse-bpf is much wider, but it does offer conditional > passthrough behavior as well. > > One of the questions is how to reference underlying files. Passing > open file descriptors directly in the fuse messages could be > dangerous[4]. Setting up the mapping from an open file descriptor to > the kernel using an ioctl() instead should be safe. > > Other open issues: > > - what shall be the lifetime of the mapping? > > - does the mapped open file need to be visible to userspace? > Remember, this is a kernel module, so there's no process involved > where you could look at /proc/PID/fd. Adding a kernel thread for each > fuse instance that installs these mapped fds as actual file descriptor > might be the solution. > > Thanks, > Miklos > > > [1] https://lore.kernel.org/all/CAJfpegtjEoE7H8tayLaQHG9fRSBiVuaspnmPr2oQiOZXVB1+7g@xxxxxxxxxxxxxx/ > > [2] https://lore.kernel.org/all/20210125153057.3623715-1-balsini@xxxxxxxxxxx/ > > [3] https://lore.kernel.org/all/20221122021536.1629178-1-drosen@xxxxxxxxxx/ > > [4] https://lore.kernel.org/all/CAG48ez17uXtjCTa7xpa=JWz3iBbNDQTKO2hvn6PAZtfW3kXgcA@xxxxxxxxxxxxxx/ I'd be very interested to discuss fuse-bpf, and how it aligns with the other efforts. I recall there being some io uring effort as well, though I haven't looked into that too much yet. Currently there are plenty of open areas for discussion with how the bpf side of fuse-bpf interacts with the userspace daemon, particularly if you create a node via bpf, and later want to handle some call for it via the daemon. I've been working on switching fuse-bpf over to using bpf's struct_ops and kfuncs, along with dynptrs which open up a lot more opportunities for adding capabilities on the bpf side. For the file descriptor passing, I'm currently using an ioctl that acts as a mirror of the /dev node. Normal fuse responses to lookup that add a backing file are rejected unless they take the ioctl path. -Daniel
