From: Christoph Hellwig <hch@infradead.org>
To: Zorro Lang <zlang@redhat.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
David Disseldorp <ddiss@suse.de>,
fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] tests: _fail on _scratch_mkfs_sized failure
Date: Fri, 26 Apr 2024 22:58:21 -0700 [thread overview]
Message-ID: <ZiyT_a4b5RJIgZ5u@infradead.org> (raw)
In-Reply-To: <20240412192831.untkqteorxsycrfw@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On Sat, Apr 13, 2024 at 03:28:31AM +0800, Zorro Lang wrote:
> > I wonder, how many tests should keep going if _scratch_mkfs_sized isn't
> > successful? Would it be simpler to make a _try_scratch_mkfs_sized for
> > those callers, and make the main _scratch_mkfs_sized simply do
> >
> > _scratch_mkfs_sized()
> > {
> > _try_scratch_mkfs_sized $* || _fail "_scratch_mkfs_sized failed"
> > }
> >
> > ?
>
> I agree with this. Actually I don't know what's kind of historical reasons
> make _scratch_mount _fail directly if mount fails, but _scratch_mkfs
> doesn't like that?
Agreed. Unsupported mkfs should absolutely fail by default. For some
tests instead of _fail it should be _notsupported, but that would be a
separate helper and between the two of them we'd cover almost all uses.
next prev parent reply other threads:[~2024-04-27 5:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 6:32 [PATCH 1/2] common/config: export TEST_DEV for mkfs.xfs David Disseldorp
2024-04-11 6:32 ` [PATCH 2/2] tests: _fail on _scratch_mkfs_sized failure David Disseldorp
2024-04-12 15:48 ` Darrick J. Wong
2024-04-12 19:28 ` Zorro Lang
2024-04-27 5:58 ` Christoph Hellwig [this message]
2024-04-12 15:44 ` [PATCH 1/2] common/config: export TEST_DEV for mkfs.xfs Darrick J. Wong
2024-04-27 5:56 ` Christoph Hellwig
2024-04-28 5:37 ` Zorro Lang
2024-04-29 11:28 ` David Disseldorp
2024-04-29 13:37 ` Zorro Lang
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=ZiyT_a4b5RJIgZ5u@infradead.org \
--to=hch@infradead.org \
--cc=ddiss@suse.de \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=zlang@redhat.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 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.