Re: [RFC PATCH] fs: allow opening overlayfs/erofs layers through O_ALT

Amir Goldstein [off-list ref] writes:

quoted

quoted

And the smaller details really show how inelegant this model is and why
Al and I have opposed it multiple times before. Scalar options are
modeled as symlinks and non-path options are dangling links whose
readlink still returns the value while for path options readlink returns
the option string but following the link jumps somewhere else entirely.

Hey, this is was a prototype to show that this can do what Giuseppe
needs.  Not with nicely polished interfaces.

I want to do a sidebar regarding "what Giuseppe needs".

As I wrote I am all for introspection of overlayfs layers, but I was never
fully convinced that getting an open fd was the correct API.

The starting point of the use case is a userspace daemon that wants
to reuse mounted erofs images, which are used as lower layers.

When considering a single daemon (e.g. composefs) this reuse
would be better done completely in userspace without kernel involvement.

The reason for a need for kernel UAPI for introspection of layers was
to allow cross daemon optimizations, so that containerd could reuse
erofs images mounted by composefs.

This optimization works under the assumption that the image file
or the image file hash is a unique identifier of the desired lower layer.

But what if composefs mounted the image with idmapping or some other
property?

And how many container runtimes are there out there?
Is it really worth the elaborate effort to provide introspection
to this level?

My intuition is that introspection should provide static information
like uuid/fsid/fhandle rather than an open fd.

I am willing to be convinced otherwise with the proper arguments.

Thanks,
Amir.

My end goal is to retrieve the EROFS mount itself that was used as an
overlay lower layer so that it can be reused across multiple overlay
mounts.
I'd like to do it without requiring a daemon to keep the file descriptor
open.  If the daemon crashes or is terminated for any reason, it can't
retrieve this information from the kernel anymore, and the daemon must
also worry about closing the file descriptor when it's no longer used by
any mount.  It seems like an unnecessary duplication of state given the
kernel already knowns about that.

How can the uuid/fsid/fhandle alone be used to solve this?  The overlay
mounts are private mounts that cannot be accessed anymore, even if you
know their handle.

In fact, before posting these patches I thought about extending
open_by_handle_at to work with mounts, in addition to namespaces and
pidfds.  Christian didn't agree with this idea and suggested the
introspection API for overlay.  IMO, this functionality would solve the
problem in a very elegant way, because we could store the handle for the
EROFS mount in a file and try to reuse it later.  On ESTALE, the mount
is recreated.  This would need only some locking, without the daemon
duplicating the kernel state.

Regards,
Giuseppe