Re: [PATCH] ovl: add ioctls to retrieve layer file descriptors
"Colin Walters" <[email protected]> Wed, 08 Jul 2026 16:16:42 -0400
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-api,org.kernel.vger.linux-fsdevel,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <[email protected]> |
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 poi= nt paths. You're right that it=E2=80=99d be possible to do this in user space.=20 However, overlayfs is used by many things (it=E2=80=99s a powerful =E2=80= =9CSwiss army knife=E2=80=9D!) and this ability to reliably introspect i= ts components is I think generally useful. For example: https://github.com/systemd/systemd/issues/35017#issuecommen= t-2457333218 Various tools want to know the backing filesystem(s) and/or block device= s thereof, and if we don=E2=80=99t have something like this in the gener= al case every overlayfs user would need to agree on a scheme to store th= is 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 s= erver for the original use case here? Maybe. I could personally go eithe= r 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 righ= t away.