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@xxxxxxxxx> wrote: > > On Mon, Sep 12, 2022 at 5:22 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Mon, 12 Sept 2022 at 15:26, Amir Goldstein <amir73il@xxxxxxxxx> 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.
