On Wed, Jul 8, 2026, at 3:01 PM, Amir Goldstein wrote:

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.

You're right that it’d be possible to do this in user space. 

However, overlayfs is used by many things (it’s a powerful “Swiss army knife”!) and this ability to reliably introspect its components is I think generally useful.

For example: https://github.com/systemd/systemd/issues/35017#issuecomment-2457333218

Various tools want to know the backing filesystem(s) and/or block devices thereof, and if we don’t have something like this in the general case every overlayfs user would need to agree on a scheme to store this data out of band - and manage its lifecycle as mounts change and deal with where that data is stored with respect to mount namespaces etc.

Even if we had this API, would it be better to have a user space cache server for the original use case here? Maybe. I could personally go either way.

But the introspection I think really would be generally useful and there are code bases (in systemd and in composefs at least) that would start using it (with fallback for old kernels) for at least that use case right away.