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 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
