All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <eguan@redhat.com>
Cc: Eric Biggers <ebiggers@google.com>, fstests@vger.kernel.org
Subject: Re: xfstests mount options?
Date: Thu, 27 Oct 2016 11:46:31 +1100	[thread overview]
Message-ID: <20161027004631.GB22126@dastard> (raw)
In-Reply-To: <20161026094724.GT27776@eguan.usersys.redhat.com>

On Wed, Oct 26, 2016 at 05:47:24PM +0800, Eryu Guan wrote:
> On Mon, Oct 24, 2016 at 11:46:11AM -0700, Eric Biggers wrote:
> > Hi,
> > 
> > When starting xfstests without $TEST_DEV mounted, it mounts it using this
> > command in _test_mount, called from init_rc:
> > 
> >     _mount -t $FSTYP $TEST_OPTIONS $TEST_FS_MOUNT_OPTS $SELINUX_MOUNT_OPTIONS $* $TEST_DEV $TEST_DIR
> 
> In my understanding, TEST_FS_MOUNT_OPTS is used for TEST_DEV, as
> MOUNT_OPTIONS is used for SCRATCH_DEV.
> 
> Looking through the git history, TEST_FS_MOUNT_OPTS was introduced by
> commit ab526a6 in 2006 without any documents. It replaced MOUNT_OPTIONS
> in _test_mount(). So I think its intention is used as mount options for
> TEST_DEV.

> 
> > 
> > This is also used by _test_cycle_mount, which some tests use.
> > 
> > This is inconsistent with the later code in _check_generic_filesystem, called
> > after each test, which remounts $TEST_DEV:
> > 
> >     _mount_or_remount_rw "$MOUNT_OPTIONS" $device $mountpoint
> 
> _check_generic_filesystem is used in both _check_test_fs() and
> _check_scratch_fs(), I think it should use different mount options based
> on which device it's checking, not use MOUNT_OPTIONS always.

Right - we have _scratch_mount_options() for returning the
configured mount options for a scratch device.  We should extract a
similar helper out of _test_mount(), and use them appropriately
where necessary.

i.e. nothing should really be using $MOUNT_OPTIONS or
$TEST_FS_MOUNT_OPTS directly - they should always get them from
the _scratch_mount_options/_test_mount_options functions...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2016-10-27  0:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 18:46 xfstests mount options? Eric Biggers
2016-10-26  9:47 ` Eryu Guan
2016-10-27  0:46   ` 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=20161027004631.GB22126@dastard \
    --to=david@fromorbit.com \
    --cc=ebiggers@google.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.