On Fri, Jul 31, 2020 at 4:13 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>
> 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.
>
I guess the confusion is what defines a "test".
A specific xfstests test script (e.g. overlay/060) defines:
- requirements (run or skip)
- setup and operations to execute
- expectations
So when you pass extra mount options it might:
- cause test not to meet requirements and be skipped
- affect the setup/operations
- usually it does not change the expectations
But you can also define some global options like
USE_KMEMLEAK, TEST_XFS_REPAIR_REBUILD, TEST_XFS_SCRUB
which affect the validations that are run after each test
in *addition* to the specific expectations encoded in the test script.
A specific unionmount test (e.g. tests/rename-pop-dir.py) defines only:
- operations to execute
- expected return value
But the test engine performs extra validations after *each* operation
in addition to verifying the expected return value.
So when I write "verify st_blocks == 0 on upper", this is not an expectation
that is explicitly written in any specific test.
The test engine records the state of objects before and after each filesystem
operation is executed to know for each object if it is expected to be lower,
metacopy,upper and then it runs some validations after each operation
(like upper st_blocks) to verify that the actual state of the object matches the
expected state.
The test run option --xdev only is similar to the xfstests requirement
and it skips a few dir rename tests and changes expected return
value in others.
But the test run options --verify, --meta, --xino, --verify, are global test
options which determine what sort of validations are performed after
each and every operation in all the operations of all of the test cases.
Those checks are implemented in context.py functions:
check_dev_ino(), check_copy_up(), check_layer()
Is my explanation more clear now?
It is clear why unionmount needs to parse mount options in order
to set the expectations from validators?
If that is clear, please review my proposal to see if I missed anything.
Thanks,
Amir.
