On Mon, 12 Sept 2022 at 15:03, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, 12 Sept 2022 at 14:29, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Mon, Sep 12, 2022 at 12:29 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > On Sat, 10 Sept 2022 at 10:52, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > BTW, I see that the Android team is presenting eBPF-FUSE on LPC > > > > coming Tuesday [1]. > > > > > > At first glance it looks like a filtered kernel-only passthrough + > > > fuse fallback, where filtering is provided by eBPF scripts and only > > > falls back to userspace access on more complex cases. Maybe it's a > > > good direction, we'll see. > > > > Yeh, we'll see. > > > > > Apparently the passthrough case is > > > important enough for various use cases. > > > > > > > Indeed. > > My use case is HSM and I think that using FUSE for HSM is becoming > > more and more common these days. > > HSM? > > > > > One of the things that bothers me is that both this FUSE_PASSTHROUGH > > patch set and any future eBPF-FUSE passthrough implementation is > > bound to duplicate a lot of code and know how from overlayfs > > (along with the bugs). > > > > We could try to factor out some common bits to a kernel fs passthough > > library. > > Yeah, although fuse/passthrough might not want all the complexity. > Getting rid of the context switch latency is the easy part. Getting > rid of dcache duplication is the hard one, though it seems that the s/dcache/page cache/ > current level of hacks in overlayfs seems sufficient and nobody much > cares for the corner cases (or works around them). > > > > > Anotehr options to consider is not to add any passthrough logic > > to FUSE at all. > > > > Instead, implement a "switch" fs to choose between passthrough > > to one of several underlying fs "branches", where one of the branches > > could be local fs and another a FUSE fs (i.e. for the complex cases). > > st_dev/st_ino management might become a headache (as it is in overlayfs). > > Thanks, > Miklos
