All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Dave Chinner <david@fromorbit.com>,
	Omer Zilberberg <Omer.Zilberberg@netapp.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/4[13,62]: restore TEST mount options
Date: Tue, 31 Oct 2017 12:37:58 +0800	[thread overview]
Message-ID: <20171031043758.GF17339@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20171030203658.GA4094@dastard>

On Tue, Oct 31, 2017 at 07:36:58AM +1100, Dave Chinner wrote:
> On Mon, Oct 30, 2017 at 10:08:31AM +0200, Omer Zilberberg wrote:
> > These tests locally change the TEST_FS_MOUNT_OPTS/MOUNT_OPTIONS
> > environment variables, and run _test_cycle_mount. As a result, following
> > tests using the TEST mount point may start with different mount options,
> > depending on run order.
> 
> I don't think that's the case. The change of the environment
> variable should only affect the current test process and it's
> children. When the test exits, we go back to the environment of the
> check process, where the TEST_FS_MOUNT_OPTS environment variable is
> still correctly set, and all future tests inherit from that. i.e.:
> 
> $ export FOO=foo
> $ echo $FOO
> foo
> $ bash
> $ echo $FOO
> foo
> $ export FOO=bar
> $ echo $FOO
> bar
> $ exit
> $ echo $FOO
> foo
> $
> 
> And after each test, check runs _check_filesystems(), which cycles
> the test mount, so for each new test process that is run they should
> already start in the correct state...

I agreed, the changing of variables in a sub-shell won't affect the
parent's copy, and check will restore the mounts with the untouched
options.

But the problem is that _check_test_fs() will cycle mount TEST_DEV with
MOUNT_OPTIONS not TEST_FS_MOUNT_OPTS, so if you have different mount
options set for TEST_DEV and SCRATCH_DEV, you'll see mount options
changed for TEST_DEV. e.g.

MOUNT_OPTIONS="-o dax" TEST_FS_MOUNT_OPTS="" ./check generic/413 generic/445
generic/445 mount TEST_DEV with "-o dax" too

MOUNT_OPTIONS="" TEST_FS_MOUNT_OPTS="-o dax" ./check generic/413 generic/445
generic/445 mount TEST_DEV without "-o dax"

MOUNT_OPTIONS="-o dax" TEST_FS_MOUNT_OPTS="-o dax" ./check generic/413 generic/445
both tests and both devices mount with "-o dax"

That's been discussed in this thread:
https://patchwork.kernel.org/patch/9742039/

Omer, can you please confirm if you're hitting this issue?

I think fixing _check_<fs>_filesystem() is the correct way. And I guess
we can refactor out a common function and call it in
_check_[xfs|btrfs|generic]_filesystem, pass the correct mount options
based on what device we're working on.

Thanks,
Eryu

  reply	other threads:[~2017-10-31  4:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30  8:08 [PATCH] generic/4[13,62]: restore TEST mount options Omer Zilberberg
2017-10-30 20:36 ` Dave Chinner
2017-10-31  4:37   ` Eryu Guan [this message]
2017-10-31 10:25     ` Omer Zilberberg
2017-10-31 11:34       ` Eryu Guan
2017-11-01 12:06         ` Omer Zilberberg
2017-11-01 12:52           ` Eryu Guan
2017-11-01 15:03             ` Omer Zilberberg
2017-11-02 12:13               ` Eryu Guan
2017-11-05 14:20                 ` Omer Zilberberg
2017-10-31 22:08     ` Dave Chinner

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=20171031043758.GF17339@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=Omer.Zilberberg@netapp.com \
    --cc=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.