From: "Darrick J. Wong" <djwong@kernel.org>
To: David Disseldorp <ddiss@suse.de>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/027: use 300M FS to accommodate XFS limits
Date: Wed, 10 Apr 2024 08:28:06 -0700 [thread overview]
Message-ID: <20240410152806.GH634366@frogsfrogsfrogs> (raw)
In-Reply-To: <20240410070720.9035-1-ddiss@suse.de>
On Wed, Apr 10, 2024 at 05:07:20PM +1000, David Disseldorp wrote:
> As of xfsprogs commit 6e0ed3d1 ("mkfs: stop allowing tiny filesystems")
> attempts to create XFS filesystems sized under 300M fail.
>
> Lacking MIN_FSSIZE configuration, failure of _scratch_mkfs_sized() in
> generic/027 doesn't halt the test, leading _scratch_mount() to mount any
> previously created (full-size) filesystem. As a result create_file()
> may loop near-endlessly awaiting ENOSPC.
>
> Use a 300M sized filesystem to support XFS' limit, and explicitly check
> for _scratch_mkfs_sized() failure to avoid endless loops if the limit
> changes again in future.
Hmmm. Does your test environment export (as in, the bash keyword)
TEST_DEV and TEST_DIR? mkfs.xfs is supposed to detect fstests and allow
sub-300M filesystems for testing.
The detection breaks if TEST_{DEV,DIR} are set but not exported in the
config file; perhaps fstests ought to be exporting them like it does for
the <cough> other detection key.
--D
> Signed-off-by: David Disseldorp <ddiss@suse.de>
> ---
> tests/generic/027 | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/generic/027 b/tests/generic/027
> index 47f1981d..4f8cf6d8 100755
> --- a/tests/generic/027
> +++ b/tests/generic/027
> @@ -35,13 +35,14 @@ _require_scratch
>
> echo "Silence is golden"
>
> -_scratch_mkfs_sized $((256 * 1024 * 1024)) >>$seqres.full 2>&1
> +_scratch_mkfs_sized $((300 * 1024 * 1024)) >>$seqres.full 2>&1 \
> + || _fail "_scratch_mkfs_sized failed"
> _scratch_mount
>
> echo "Reserve 2M space" >>$seqres.full
> $XFS_IO_PROG -f -c "pwrite 0 2m" $SCRATCH_MNT/testfile >>$seqres.full 2>&1
> echo "Fulfill the fs" >>$seqres.full
> -$XFS_IO_PROG -f -c "pwrite 0 254m" $SCRATCH_MNT/bigfile >>$seqres.full 2>&1
> +$XFS_IO_PROG -f -c "pwrite 0 298m" $SCRATCH_MNT/bigfile >>$seqres.full 2>&1
> echo "Remove reserved file" >>$seqres.full
> rm -f $SCRATCH_MNT/testfile
>
> --
> 2.35.3
>
>
next prev parent reply other threads:[~2024-04-10 15:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 7:07 [PATCH] generic/027: use 300M FS to accommodate XFS limits David Disseldorp
2024-04-10 15:28 ` Darrick J. Wong [this message]
2024-04-11 1:53 ` David Disseldorp
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=20240410152806.GH634366@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=ddiss@suse.de \
--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.