From: Christoph Hellwig <hch@lst.de>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Christoph Hellwig <hch@lst.de>, Zorro Lang <zlang@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: RFC: don't fail tests when mkfs options collide
Date: Tue, 23 Jul 2024 15:39:04 +0200 [thread overview]
Message-ID: <20240723133904.GA20005@lst.de> (raw)
In-Reply-To: <20240723035016.GB3222663@mit.edu>
On Mon, Jul 22, 2024 at 11:50:16PM -0400, Theodore Ts'o wrote:
> Yeah, it's a bit of a mess. It's not been an issue for ext4 because
> mkfs.ext4 allows options specified later in the command-line to
> override earlier ones.
At least in my case it's not really by overriding. E.g. if I force
an allocation group (or block group in extN terms) to a specific size
and then want a log that is larger than that, changing the AG size
is generally a bad idea, and a clear warning to the user is simply the
better interface.
> There's a third possibility, which is sometimes the test might
> explicitly want the mkfs options to be merged together. For example,
> in the ext4/4k configuration we have "-b 4096", while the ext4/1k
> confiuration option we might have "-b 1024". And we might want to
> have that *combined* with a test which is enabling fscrypt feature, so
> we can test fscrypt with a 4k block size, as well as fsvrypt with a 1k
> blocksize.
>
> That being said, that doesn't always make sense, and sometimes the
> combination doesn't make any sense.
Merging the options is what we're currently doing, and it works ok
most of the time. The question is what to do when it doesn't.
next prev parent reply other threads:[~2024-07-23 13:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 0:00 RFC: don't fail tests when mkfs options collide Christoph Hellwig
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 [this message]
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=20240723133904.GA20005@lst.de \
--to=hch@lst.de \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
--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