($INBOX_DIR/description missing)
 help / color / Atom feed
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
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:
> And now that xfstests has helpers to convert xfstests env vars to
> UNIONMOUNT_* env vars, one might ask: why won't we support
> 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.


> 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:
> Does anyone spot any obvious flaws in this plan before I make those changes?
> Thanks,
> Amir.
> [1] https://github.com/amir73il/xfstests/commits/unionmount

  reply index

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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-unionfs/0 linux-unionfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-unionfs linux-unionfs/ https://lore.kernel.org/linux-unionfs \
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git