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".
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx
