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. 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? 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.
