From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [RFC] Passing extra mount options to unionmount tests
Date: Fri, 31 Jul 2020 09:12:44 -0400 [thread overview]
Message-ID: <20200731131244.GA189839@redhat.com> (raw)
In-Reply-To: <CAOQ4uxjWc8WFRFS8GTpz8uE1AHrs6yGx2A3fZy-Sxfu7CCyKuw@mail.gmail.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
>
next prev parent reply other threads:[~2020-07-31 13:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-04 15:11 [RFC] unionmount metacopy tests Amir Goldstein
2019-07-09 14:13 ` Vivek Goyal
2020-07-31 12:35 ` [RFC] Passing extra mount options to unionmount tests Amir Goldstein
2020-07-31 13:12 ` Vivek Goyal [this message]
2020-07-31 14:09 ` Amir Goldstein
2020-07-31 18:21 ` Vivek Goyal
2020-07-31 20:02 ` Amir Goldstein
2020-08-13 11:23 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200731131244.GA189839@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).