FS/XFS testing framework
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Zorro Lang <zlang@kernel.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: RFC: don't fail tests when mkfs options collide
Date: Mon, 22 Jul 2024 17:00:31 -0700	[thread overview]
Message-ID: <20240723000042.240981-1-hch@lst.de> (raw)

Hi all,

I've been running some tests with forced large log sizes, and forced
sector sizes, and get a fair amount of failures because these options
collide with options forced by the tests themselves.  The series here was
my attempt to fix this by not failing the tests in this case but _notrun
them and print the options that caused them to fail.

While writing up this cover letter I realized that the scratch fs options
are much deeper mess than that, so this approach might not be what we
actually want, but I though to send it out for comments anyway.

So what could we do instead?  We might distinguish better between tests
that just want to create a scratch file system with $MKFS_OPTIONS from
the xfstests config, and those (file system specific ones) that want
to force very specific file system configurations.  How do we get
there?

A first step might be to split up _scratch_mkfs into a plain
_scratch_mkfs that never takes any options, and a _scratch_mkfs_opts that
takes options.  The former should never fail as that would be a grave
error rendering all $SCRATCH_DEV based tests useless. The latter can and
should _notrun when the options conflict, or they might be able to do
some limited filtering to reduce the amount of conflict, but I suspect
that is kinda futile.

Last but not least we should probably kill the separate _scratch_mkfs_xfs
(and _scratch_mkfs_ext4) which is used rather inconsistently.

             reply	other threads:[~2024-07-23  0:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23  0:00 Christoph Hellwig [this message]
2024-07-23  0:00 ` [PATCH 1/4] common: _notrun if _scratch_mkfs_sized failed Christoph Hellwig
2024-07-23  0:00 ` [PATCH 2/4] common: _notrun if _scratch_mkfs_xfs failed Christoph Hellwig
2024-07-26 17:14   ` Zorro Lang
2024-07-26 18:11     ` Christoph Hellwig
2024-07-28 14:54   ` Zorro Lang
2024-07-29 14:17     ` Christoph Hellwig
2024-07-23  0:00 ` [PATCH 3/4] xfs/432: use _scratch_mkfs_xfs Christoph Hellwig
2024-07-23  0:00 ` [PATCH 4/4] xfs/516: " Christoph Hellwig
2024-07-23  3:50 ` RFC: don't fail tests when mkfs options collide Theodore Ts'o
2024-07-23 13:39   ` Christoph Hellwig
2024-07-23 14:17     ` Theodore Ts'o
2024-07-23 14:20       ` Christoph Hellwig
2024-07-26 16:20       ` Darrick J. Wong
2024-07-26 17:11         ` Christoph Hellwig
2024-07-28  2:24           ` Darrick J. Wong

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=20240723000042.240981-1-hch@lst.de \
    --to=hch@lst.de \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox