Re: Do I really need to add mount2 and umount3 syscalls for some crazy experiment

[Amir Goldstein <amir73il@gmail.com>]

On Mon, Jan 9, 2023 at 7:08 AM Anadon <joshua.r.marshall.1991@gmail.com> wrote:
>
> I never post, be gentle.
>
> I am looking into implementing a distributed RAFT filesystem for
> reasons.  Before this, I want what is in effect a simple pass-through
> filesystem.  Something which just takes in calls to open, read, close,
> etc and forwards them to a specified mounted* filesystem.  Hopefully
> through FUSE before jumping straight into kernel development.
>
> Doing this and having files appear in two places by calling `mount()`
> then calling the (potentially) userland functions to the mapped file
> by changing the file path is a way to technically accomplish
> something.  This has the effect of the files being accessible in two
> locations.  The problems start where the underlying filesystem won't
> notify my passthrough layer if there are changes made.  Since my end
> goal is to have a robust consensus filesystem, having all the files
> able to silently be modified in such an easy and user accessible way
> is a problem.

Have you considered using fanotify for the FUSE implementsation?

You can currently get async change notifications from fanotify.
Do you require synchronous change notifications?
Do you require the change notifications to survive system crashes?

Because that is what my HSM fanotify project is aiming to achieve:
https://github.com/amir73il/fsnotify-utils/wiki/Hierarchical-Storage-Management-API#tracking-local-modifications

> What would be better is to have some struct with all
> relevant function pointers and data accessible.  That sounds like
> adding syscalls `int mount2(const char* device, ..., struct
> return_fs_interface)` and `int umuont3(struct return_fs_interface)`.
> Adding two new syscalls which look almost nothing like other syscalls
> all in the name to break "everything is a file" in favor of
> "everything is an API" is a lot.  It sounds like a fight and work I
> would like to avoid.

Don't go there.

>
> I have looked at `fsopen(...)` as an alternative, but it still does
> not meet my use case.  Another way would be to compile in every
> filesystem driver but this just seems downright mad.  Is there a good
> option I have overlooked?  Am I even asking in the right place?

If you are looking for similar code, the overlayfs filesystem driver
is probably the closest to what you are looking for in upstream
kernel, because it takes two underlying paths and merges them
in one unified namespace.

Somewhat similar to leader change, some union files switch the backing
file at runtime (a.k.a copy up).

Upstream overlayfs does not watch for underlying filesystem changes,
in fact, those changes are not allowed, but it could be done.
I have another project where overlayfs driver watches the underlying
filesystem for changes:
https://github.com/amir73il/overlayfs/wiki/Overlayfs-watch

The out-of-tree aufs has had underlying change tracking for a long time.

Thanks,
Amir.