($INBOX_DIR/description missing)
 help / color / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: [RFC] Passing extra mount options to unionmount tests
Date: Fri, 31 Jul 2020 15:35:40 +0300
Message-ID: <CAOQ4uxjWc8WFRFS8GTpz8uE1AHrs6yGx2A3fZy-Sxfu7CCyKuw@mail.gmail.com> (raw)
In-Reply-To: <20190709141302.GA19084@redhat.com>

> >
> > 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.  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

  reply index

Thread overview: 7+ 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   ` Amir Goldstein [this message]
2020-07-31 13:12     ` [RFC] Passing extra mount options to unionmount tests Vivek Goyal
2020-07-31 14:09       ` Amir Goldstein
2020-07-31 18:21         ` Vivek Goyal
2020-07-31 20:02           ` 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=CAOQ4uxjWc8WFRFS8GTpz8uE1AHrs6yGx2A3fZy-Sxfu7CCyKuw@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.com \
    /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

($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 \
		linux-unionfs@vger.kernel.org
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-unionfs


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