Re: [RFC] Passing extra mount options to unionmount tests

[Vivek Goyal <vgoyal@redhat.com>]

On Fri, Jul 31, 2020 at 03:35:40PM +0300, Amir Goldstein wrote:
> > >
> > > If anyone is running unionmount-testsuite on regular basis
> > > I would be happy to know which configurations are being tested,
> > > because the test matrix grew considerably since I took over the project -
> > > both Overlayfs config options and the testsuite config options.
> >
> > For me, I think I am most interested in configuration used by
> > container runtimes (docker/podman). Docker seems to turn off
> > redirects as of now. podman is turning on metacopy (hence redirect)
> > by default now to see how do things go.
> >
> > So for me (redirect=on/off and metacopy=on/off) are important
> > configurations as of now. Having said that, I think I should talk
> > to container folks and encourage them to use "index" and "xino"
> > as well to be more posix like fs.
> >
> 
> Hi Vivek,
> 
> I remember you asked me about configuring extra mount options
> for unionmount but couldn't find that conversation, so replying to this
> related old discussion with my thoughts on the subject.
> 
> Now that unionmount supports the environment variables:
> UNIONMOUNT_{BASEDIR,LOWERDIR,MNTPOINT}
> 
> And now that xfstests has helpers to convert xfstests env vars to
> UNIONMOUNT_* env vars, one might ask: why won't we support
> UNIONMOUNT_OPTIONS=$OVERLAY_MOUNT_OPTIONS
> 
> So when you asked me a question along those lines, my answer was that
> unionmount performs different validations depending on the test options,
> so for example, the test option ./run --meta adds the mount option
> "metacopy=on", but it also performs different validation tests, such as
> upper file st_blocks == 0 after metadata change.
> 
> Right, so I gave a reason for why supporting extra mount options is not
> straight forward, but that doesn't mean that it is not possible.
> unionmount test could very well parse the extra mount options passed
> in env var and translate them to test config options.

Hi Amir,

I am not able to understand this point. Why an extra mount option
needs to be translated into a "test config" option. If I pass
"metacopy=on", that does not mean that I also want to run tests
which verify st_blocks == 0 on upper. It just means that whatever
tests I am running, are run with metacopy=on. All I want to make
sure that tests I am running are not broken if run with metacopy=on.

Thanks
Vivek

> As a matter of fact,
> unionmount already parses the following overlay module parameters
> and translates the following values to test config options:
> 
> 1) redirect_dir does not exist => --xdev (expect EXDEV on dir rename)
> 2) redirect_dir exists and no explicit --xdev => add redirect_dir=on
> 3) index=N and --verify => add index=on and check st_ino validations
> 4) metacopy=Y => check --meta validations (e.g. upper st_blocks)
> 5) xino_auto=Y => add xino=on and check --xino validations (e.g. uniform st_dev)
> 
> So apart from blindly adding the extra mount options to mount command,
> will also need to translate:
> 
> 6) redirect_dir=off => --xdev
>    (redirect_dir=on conflicts with --xdev)
> 7) index=off => overrides index=on added by --verify
>    (st_ino validations should still pass on tests without multi layers)
> 8) metacopy=on => --meta
>    (metacopy=off conflicts with --meta)
> 9) xino=auto/on => --xino
>    (xino=off conflicts with --xino)
> 
> At the moment, I have a patch to xfstests [1] that implements rule 8 in the
> xfstests _unionmount_testsuite_run helper, but I came to realize that would
> be wrong and that the correct way would be to implement conversion rules
> 6-9 in unionmount itself and then blindly assign in xfstest helper:
> UNIONMOUNT_OPTIONS=$OVL_BASE_MOUNT_OPTIONS
> 
> Does anyone spot any obvious flaws in this plan before I make those changes?
> 
> Thanks,
> Amir.
> 
> [1] https://github.com/amir73il/xfstests/commits/unionmount
>