Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough

From: Hao Luo <haoluo@google.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Alessio Balsini <balsini@android.com>,
	Peng Tao <bergwolf@gmail.com>,
	Akilesh Kailash <akailash@google.com>,
	Antonio SJ Musumeci <trapexit@spawn.link>,
	David Anderson <dvander@google.com>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Jann Horn <jannh@google.com>, Jens Axboe <axboe@kernel.dk>,
	Martijn Coenen <maco@android.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Lawrence <paullawrence@google.com>,
	Stefano Duo <duostefano93@gmail.com>,
	Zimuzo Ezeozue <zezeozue@google.com>, wuyan <wu-yan@tcl.com>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	kernel-team <kernel-team@android.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough
Date: Mon, 12 Sep 2022 10:43:42 -0700	[thread overview]
Message-ID: <CA+khW7hviAT6DbNORYKcatOV1cigGyrd_1mH-oMwehafobVXVg@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjjPOtH9+r=oSV4iVAUvW6s3RBjA9qC73bQN1LhUqjRYQ@mail.gmail.com>

Sorry, resend, my response was bounced back by mail system due to not
using plain text.

On Mon, Sep 12, 2022 at 8:40 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Mon, Sep 12, 2022 at 5:22 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Mon, 12 Sept 2022 at 15:26, Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > > FWIW duplicate page cache exists in passthough FUSE whether
> > > passthrough is in kernel or in userspace, but going through yet another
> > > "switch" fs would make things even worse.
> >
> > I imagine the "switch" layer for a HSM would be simple enough:
> >
> > a) if file exists on fastest layer (upper) then take that
> > b) if not then fall back to fuse layer (lower) .
> >
> > It's almost like a read-only overlayfs (no copy up) except it would be
> > read-write and copy-up/down would be performed by the server as
> > needed. No page cache duplication for upper, and AFAICS no corner
> > cases that overlayfs has, since all layers are consistent (the fuse
> > layer would reference the upper if that is currently the up-to-date
> > one).
>
> On recent LSF/MM/BPF, BPF developers asked me about using overlayfs
> for something that looks like the above - merging of non overlapping layers
> without any copy-up/down, but with write to lower.
>
> I gave them the same solution (overlayfs without copy-up)
> but I said I didn't know what you would think about this overlayfs mode
> and I also pointed them to the eBPF-FUSE developers as another
> possible solution to their use case.
>

Thanks Amir for adding me in the thread. This idea is very useful for
BPF use cases.

A bit more context here: we were thinking of overlaying two
filesystems together to create a view that extends the filesystem at
the lower layer. In our design, the lower layer is a pseudo
filesystem, which one can _not_ create/delete files, but make
directories _indirectly_, via creating a kernel object; the upper is
bpf filesystem, from which, one can create files. The file's purpose
is to describe the directory in the lower layer, that is, to describe
the kernel object that directory corresponds to.

With the flexibility brought by BPF, it can be a quite flexible
solution to query kernel objects' states.

>
> >
> > readdir would go to the layer which has the complete directory (which
> > I guess the lower one must always have, but the upper could also).
> >
> > I'm probably missing lots of details, though...
> >
>
> That's what I said too :)
>
> Does that mean that you are open to seeing patches for
> an overlayfs mode that does not copy-up on write to lower?
> I can come up with some semantics for readdir that will
> make sense.

I am excited about this. Thanks Amir!

>
> Thanks,
> Amir.