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.
