On Fri, Jun 09, 2023 at 10:17:35AM +0200, Alexander Larsson wrote:
> On Tue, May 30, 2023 at 6:19 PM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
> > On Tue, May 30, 2023 at 04:08:38PM +0200, Miklos Szeredi 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.
> >
> > Sorry, just a quick braindump vaguely related to this new mount syntax.
> >
> > A while ago util-linux reported issues with overlayfs when mounted
> > through the new mount api (cf. [1]) and I completely forgot to mention
> > this to you during LSFMM. So say you do:
> >
> > fs_fd = fsopen("overlay", FSOPEN_CLOEXEC);
> >
> > fsconfig(fs_fd, FSCONFIG_SET_STRING, "upperdir", "/home/asavah/kross/tmp/asusb450eg/upper", 0);
> >
> > fsconfig(fs_fd, FSCONFIG_SET_STRING, "workdir", "/tmp/work", 0);
> >
> > fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f:20:21:22:23:24:25:26:27:28:29:2a:2b:2c:2d:2e:2f:
> >
> > This will fail because FSCONFIG_SET_STRING is limited to 256 bytes.
> > That's a reasonable limit and I don't think we need to extend this to
> > PATH_MAX.
> >
> > Instead, my reaction had been that lowerdir should be specifiable
> > multiple times through fsconfig() and overlayfs should probably append
> > lower layers via:
> >
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "/home/username/project/data1", 0);
> > // append
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", ":/home/username/project/data2", 0);
> > // append
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", ":/home/username/project/data3", 0);
> >
> > // replace everything specified until now
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "/home/username/project/data4", 0);
> >
> > // reset everything
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "", 0);
> >
> > so with the new syntax this would probably be:
> >
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "/home/username/project/data1", 0);
> > // append data only layer
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "::/home/username/project/data2", 0);
> > // append data only layer
> > ret = fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "::/home/username/project/data3", 0);
> >
> > [1]: https://github.com/util-linux/util-linux/issues/1992
>
> Btw. I forgot to mention this, but I ran into an issue with overlayfs
> and the new mount api. In order to be able to pass in any pathname in
> the
> lowerdir option, overlayfs escapes commas, like:
>
> -o lowerdir=/lower/dir/with\,commas,upperdir=/upper
>
> This is handled in overlayfs in ovl_split_lowerdirs() and ovl_unescape().
>
> However, when using the new mount APIs, currently overlayfs uses
> legacy_fs_context_ops, and legacy_parse_param() forbids commas in the
> string, even if it is escaped. So the above mount will fail with "VFS:
> Legacy: Option '%s' contained comma".
I've sent a patch yesterday that converts overlayfs to the new mount api
that would also fix this fwiw.
