Amir Goldstein <[email protected]> writes: > On Wed, Jul 8, 2026 at 5:55 PM Giuseppe Scrivano <[email protected]> wrote: >> >> Miklos Szeredi <[email protected]> writes: >> >> > On Wed, 8 Jul 2026 at 16:32, Giuseppe Scrivano <[email protected]> wrote: >> > >> >> Amir suggested to add that functionality when I've asked for some >> >> feedback before sending the patch here. I am fine to drop it if this is >> >> the consensus although I see its utility from user space. > > I was thinking that getting the number of layers or info would be > a good idea to complement getting a layer fd. > > I agree that the same information is probably available via statmount > by parsing the upperdir/lowerdir/datadir mount options. > >> > >> > How about a completely different interface: >> > >> > int get_fd_opt(const char *name, unsigned int index, unsigned int flags); >> > >> > Enumerating layers would be as easy as passing an index stating from >> > zero and stopping when -ERANGE is received. >> > >> > It would work for all filesystems that use files as options. No more >> > fs specific ioctls. >> >> Is a new syscall really justified for such a narrow use case? >> > > I feel the same way. > > Giuseppe, > > Could you add some high level context in this thread on why you need > this functionality. > I think it's this composefs-rs work. right? > https://github.com/giuseppe/composefs-rs/commits/reuse-mounts-and-prevent-gc-overlay/ > > I must say this seems a bit upside down to me. > > If you want to keep a pool of mounted erofs images, you could do that > in userspace - > create a service that indexes mounted erofs images by unique mount point > paths. > Then you can introspect the overlayfs mount options referring to those > mount points.
A first issue is that the mount options won't have this information anymore, as we use /proc/self/fd/$i paths as lower dirs so we are sure the fd points exactly to the file we have measured its fs-verity digest before using it. I know this can be achieved with a system daemon, but do we really need one if this information is already known to the kernel? Combined with listmount/statmount for discovery and fs-verity for validation, the entire mechanism is stateless from userspace. More in general we need a way to introspect overlay mounts to know where they are pointing to since paths can be hidden using /proc/*/fd symlinks, or files get replaced. Another similar request: https://github.com/systemd/systemd/issues/35017#issuecomment-2457333218 > Going through the kernel to get an fd and reuse that fd for a new > overlayfs mount > sounds like a strange way of accomplishing this. > > If the overlayfs mounter is unprivileged, it would have to go through > systemd-mountfsd > to request a mount of erofs trusted image, right? off-topic but for now we are considering FUSE to deal with mounting EROFS as it would serve only the metadata anyway in a composefs setup. Regards, Giuseppe > Can't the same service provide the "is_image_mounted" query which provides > the mount path? > > I am not against introspection of overlayfs, but I'd like to understand > the use cases before finalizing the uapi. > > Thanks, > Amir.
