From: "Darrick J. Wong" <djwong@kernel.org>
To: Daniel Gomez <da.gomez@samsung.com>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>,
Pankaj Raghav <p.raghav@samsung.com>,
"mcgrof@kernel.org" <mcgrof@kernel.org>,
"hughd@google.com" <hughd@google.com>
Subject: Re: [PATCH 4/5] common/rc: fix scratch mount options for tmpfs
Date: Mon, 24 Jun 2024 09:47:15 -0700 [thread overview]
Message-ID: <20240624164715.GI103020@frogsfrogsfrogs> (raw)
In-Reply-To: <jnyfwimjjfi56fqbfb4lvrauzinkgokdsftxa4k4o5o7eomokm@ghgk5vt46rcz>
On Mon, Jun 24, 2024 at 01:50:33PM +0000, Daniel Gomez wrote:
> On Fri, Jun 14, 2024 at 08:47:28AM GMT, Darrick J. Wong wrote:
> > On Fri, Jun 14, 2024 at 06:17:25AM +0000, Daniel Gomez wrote:
> > > Make sure tmpfs scratch device inherits the extra tmpfs mount options
> > > variable (TMPFS_MOUNT_OPTIONS).
> > >
> > > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > > ---
> > > common/rc | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/common/rc b/common/rc
> > > index 7f995b0fa..a42792c37 100644
> > > --- a/common/rc
> > > +++ b/common/rc
> > > @@ -224,7 +224,7 @@ _test_options()
> > > # hosted on $SCRATCH_DEV, so can't use external scratch devices).
> > > _common_dev_mount_options()
> > > {
> > > - echo $MOUNT_OPTIONS $SELINUX_MOUNT_OPTIONS $*
> > > + echo $MOUNT_OPTIONS $SELINUX_MOUNT_OPTIONS $TMPFS_MOUNT_OPTIONS $*
> >
> > Why is it necessary to include tmpfs mount options for all fs types?
> > XFS does not accept tmpfs mount options.
>
> You are right. We should not do this.
>
> However, _scratch_mount_options() calls _common_dev_mount_options() ignoring the
> specific mount options based on fstyp.
Ah, _mount_opts only gets run for configuration files.
> specific mount options based on fstyp. Replacing it with _common_mount_opts()
> makes this work. In addition, _common_dev_mount_options() function description
> says 'Used for mounting non-scratch devices with the safe set of scratch mount
> options'. So, why is it used to mount scratch devices?
I think the comment isn't very good. Six of the seven callers:
common/dmdelay|23| _mount -t $FSTYP `_common_dev_mount_options` $SCRATCH_OPTIONS \
common/dmdust|19| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmerror|94| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmlogwrites|107| _mount -t $FSTYP `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
common/dmthin|226| echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS $DMTHIN_VOL_DEV $SCRATCH_MNT
common/rc|272| echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
appear to use this to mount the scratch filesystem from devices that are
not the regular scratch device. The one exception is this one:
common/overlay|32| _mount -t overlay $diropts `_common_dev_mount_options $*`
which AFAICT seem to mount arbitrary overlayfs instances with some of
the mount options.
> This fixes the issue:
>
> diff --git a/common/rc b/common/rc
> index 51827119c..627dbaaaa 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -231,8 +231,8 @@ _scratch_mount_options()
> {
> _scratch_options mount
>
> - echo `_common_dev_mount_options $*` $SCRATCH_OPTIONS \
> - $SCRATCH_DEV $SCRATCH_MNT
> + echo `_common_mount_opts` $SCRATCH_OPTIONS \
> + $SCRATCH_DEV $SCRATCH_MNT $*
> }
>
> >
> > For that matter, why is TMPFS_MOUNT_OPTIONS necessary at all? Shouldn't
> > that simply be "MOUNT_OPTIONS=<stuff> FSTYP=tmpfs ./check" ?
>
> TMPFS_MOUNT_OPTIONS is used to specify mount options in each section of the
> configuration file. For example, the following snippet is part of my conf file:
>
> ```
> [tmpfs_noswap_huge_always]
> TMPFS_MOUNT_OPTIONS="-o noswap,huge=always"
>
> [tmpfs_noswap_huge_within_size]
> TMPFS_MOUNT_OPTIONS="-o noswap,huge=within_size"
> ```
>
> Then I run -s option to switch between profiles, e.g., 'check -s
> tmpfs_noswap_huge_within_size -R xunit -g auto'.
>
> I’m not sure if this addresses your question. Please let me know if I
> misunderstood.
Ahah, this is one of those parts of fstests that differ depending on
whether you use configuration files (you do) or not (I don't). AFAICT,
get_next_config has this slightly odd (to me) behavior where if a config
section doesn't explicitly set MOUNT_OPTIONS, it will reuse
MOUNT_OPTIONS from a previous section if FSTYP hasn't changed. You
instead want to change the mount between sections
So I /think/ the correct thing to do here is
[tmpfs_noswap_huge_always]
MOUNT_OPTIONS="-o noswap,huge=always"
[tmpfs_noswap_huge_within_size]
MOUNT_OPTIONS="-o noswap,huge=within_size"
Though I'm not exactly an expert on these things.
--D
>
> >
> > --D
> >
> > > }
> > >
> > > _scratch_mount_options()
> > > --
> > > 2.43.0
> > >
next prev parent reply other threads:[~2024-06-24 16:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240614061726eucas1p13b3cf24fce9d28ce29ee029224bf4378@eucas1p1.samsung.com>
2024-06-14 6:17 ` [PATCH 0/5] tmpfs fixes Daniel Gomez
2024-06-14 6:17 ` [PATCH 1/5] generic/449: not run on tmpfs earlier Daniel Gomez
2024-06-14 15:43 ` Darrick J. Wong
2024-06-14 6:17 ` [PATCH 2/5] common/config: fix RECREATE_TEST_DEV initialization Daniel Gomez
2024-06-14 15:44 ` Darrick J. Wong
2024-06-17 6:57 ` Zorro Lang
2024-06-14 6:17 ` [PATCH 4/5] common/rc: fix scratch mount options for tmpfs Daniel Gomez
2024-06-14 15:47 ` Darrick J. Wong
2024-06-24 13:50 ` Daniel Gomez
2024-06-24 16:47 ` Darrick J. Wong [this message]
2024-06-24 20:47 ` Daniel Gomez
2024-06-14 6:17 ` [PATCH 3/5] common/rc: add recreation support " Daniel Gomez
2024-06-14 15:48 ` Darrick J. Wong
2024-06-17 7:06 ` Zorro Lang
2024-06-24 13:33 ` Daniel Gomez
2024-06-28 3:13 ` Zorro Lang
2024-06-28 22:29 ` Daniel Gomez
2024-06-14 6:17 ` [PATCH 5/5] common/rc: print scratch and test mount options Daniel Gomez
2024-06-14 15:55 ` Darrick J. Wong
2024-06-24 14:02 ` Daniel Gomez
2024-06-24 16:24 ` Darrick J. Wong
2024-06-24 20:57 ` Daniel Gomez
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=20240624164715.GI103020@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=da.gomez@samsung.com \
--cc=fstests@vger.kernel.org \
--cc=hughd@google.com \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox