All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <eguan@redhat.com>
Cc: Omer Zilberberg <Omer.Zilberberg@netapp.com>, fstests@vger.kernel.org
Subject: Re: [PATCH] generic/4[13,62]: restore TEST mount options
Date: Wed, 1 Nov 2017 09:08:21 +1100	[thread overview]
Message-ID: <20171031220821.GB4094@dastard> (raw)
In-Reply-To: <20171031043758.GF17339@eguan.usersys.redhat.com>

On Tue, Oct 31, 2017 at 12:37:58PM +0800, Eryu Guan wrote:
> 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.

That's a bug in _check_test_fs() that needs fixing.

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

Ok, so it definitely needs fixing - using MOUNT_OPTIONS with
the test device is just simply wrong.

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

check_xfs_filesystem already takes a mount option parameter. The
problem is that it's considered "extra" and appended to
MOUNT_OPTIONS. Should be simple to fix...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      parent reply	other threads:[~2017-10-31 22:08 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
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 [this message]

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=20171031220821.GB4094@dastard \
    --to=david@fromorbit.com \
    --cc=Omer.Zilberberg@netapp.com \
    --cc=eguan@redhat.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.