Re: [PATCH] ovl: add ioctls to retrieve layer file descriptors
Miklos Szeredi <[email protected]> Fri, 10 Jul 2026 20:23:41 +0200
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-api,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <CAJfpegvGnr2a3u9qTEVgZyUpeYF0FoRg8xzyGg1wfw88Os5rMw@mail.gmail.com> |
On Thu, 9 Jul 2026 at 16:32, Amir Goldstein <[email protected]> wrote: > Ack for this, but please don't use mount/options/... it's a bit ugly > because most mount options are not opan-able. True, but I was thinking of doing this as a reverse fsconfig() thing. > Please stick to something logical like "fs/layers/N" corresponding to > ovl_fs::layers, where layer 0 is reserved for upper. > We could also support opening by aliases fs/layers/upper->0 etc, > but no rush IMO. Layer numbering has been internal to overlayfs to date. I'd prefer to keep the layer enumeration that is external, which is the mount option interface. Works for EROFS as well. > What I am contemplating is whether we should implement > introspection of the ovl_entry stack for merge dirs in addition or instead > introspection of fs/layers. Interesting. > IIRC, the root dir stack does NOT hold references to lowerdata dirs, > so support for "fs/layers/N" is still needed. So let's just stick with the per-superblock layering for now, which is reflected in the mount options. > > For directories we could implement "real/0..N" with aliases > real/upper->0 real/origin->1. > > For a regular file we could have constant aliases real/upper->0 > real/lower->1 real/lowerdata->2 and/or dynamic aliases > real/data->{0,1,2}, real/metadata->{0,1}, real/origin->{0,1}. > > Those could be used to implement "revert to origin". > Specifically, I think Daan asked for it during the last LSFMM. > Although I don't think we currently store the original lowerdata > in ovl_entry when lookup is done post data copy up. I'm trying to focus on the "return an O_PATH descriptor for stacked layers" for now. It avoids having to deal with opening files or directories within the O_ALT namespace, since magic symlink following is used. Thanks, Miklos