On Fri, Jun 9, 2023 at 10:24 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 30 May 2023 at 16:15, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Tue, May 30, 2023 at 5:08 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > On Sat, 27 May 2023 at 16:04, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > > > If we would want to support data-only layers in the middle on the > > > > stack, which would this syntax make sense? > > > > lowerdir=lower1::data1:lower2::data2 > > > > > > > > If this syntax makes sense to everyone, then we can change the syntax > > > > of data-only in the tail from lower1::data1:data2 to lower1::data1::data2 > > > > and enforce that after the first ::, only :: are allowed. > > > > > > > > Miklos, any thoughts? > > > > I have a feeling that this was your natural interpretation when you first > > > > saw the :: syntax. > > > > > > Yes, I think it's more natural to have a prefix for each data-only > > > layer. And this is also good for extensibility, as discussed. > > > > > > > Good timing ;-) > > > > I was just about to say that I changed the syntax and pushed to: > > > > https://github.com/amir73il/linux/commits/ovl-lazy-lowerdata-v3 > > https://github.com/amir73il/xfstests/commits/ovl-lazy-lowerdata > > > > The gist of the documentation of v3 is: > > > > Below the top most lower layer, any number of lower most layers may be defined > > as "data-only" lower layers, using double colon ("::") separators. > > A normal lower layer is not allowed to be below a data-only layer, so single > > colon separators are not allowed to the right of double colon ("::") separators. > > > > For example: > > > > mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged > > > > > > Do you need me to post the v3 patches? > > > > The changes since ovl-lazy-lowerdata-v2 branch are: > > - Reabse on 6.4-rc2 + NULL deref fixes > > - Syntax change > > Patches look good to me. > > Pushed v3 to overlayfs-next. > > It'd be interesting to hear what obstacles you encountered when trying > to implement generic lazy lookup. I can put that into the pull > request so the information is not lost. > Depends on what you mean by "generic lazy lookup". Generic lazy lookup in the sense that it does lazy lookup to lower (not to lowerdata) is challenging, because we use lower inode number for many things including hashing the overlay inode, which is done during lookup. The challenges with generic lazy lowerdata lookup in layers that are not data-only is that there is more state to store for the lazy lookup: - Which layer we stopped lookup - The current path, if not an absolute redirect - Maybe more? And the lazy lookup will have to resume the ovl layers lookup state machine on access including checking redirects, metacopy, etc. The current code only stores an optional absolute lowerdata_redirect string on ovl_lookup() only for the case of lowerdata lookup in data-only layers and lazy lookup calls a single vfs helper vfs_path_lookup() per data-only layer - it is quite trivial. No obstacles that I am aware of - only more work that is not driven by request from users. Thanks, Amir.
