From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
kdevops@lists.linux.dev, dave@stgolabs.net, jack@suse.cz
Subject: Re: ext4 v6.15-rc2 baseline
Date: Thu, 17 Apr 2025 13:37:11 -0500 [thread overview]
Message-ID: <20250417183711.GB6008@mit.edu> (raw)
In-Reply-To: <20250417163820.GA25655@frogsfrogsfrogs>
On Thu, Apr 17, 2025 at 09:38:20AM -0700, Darrick J. Wong wrote:
>
> generic/04[456] fail with a bunch of...
Yeah, this is known. I have an ext4-specific exclude file:
// generic/04[456] tests how truncate and delayed allocation works
// ext4 uses the data=ordered to avoid exposing stale data, and
// so it uses a different mechanism than xfs. So these tests will fail
generic/044
generic/045
generic/046
> ext4/043 seems to fail because it tries to create 128b inodes with
> project ids and fails.
Yeah, I don't enable project id quotas by default in my test setups.
And _scratch_mkfs will fallback to using just the tests's mkfs option,
so if -O quota,project are specified in MKFS_OPTS, then the fallback works:
Start test timestamps with 128 inode size one device /dev/vdc
** mkfs failed with extra mkfs options added to "-q -O quota,project" by test 043 **
** attempting to mkfs using only test 043 options: -I 128 **
I suppose we could explicitly add something like -O ^project to the
test, but enabling -O project isn't in the default e2fsprogs
mke2fs.conf, and there are probably all sorts of oddball mke2fs.conf
configurations that might cause tesets to fail.
> ext4/053 I suspect fails because built-in quota conflicts with the quota
> mount options.
Hmm, I can't reproduce this with "kvm-xfstests -c ext4/quota
ext4/053", which will configure xfstests with:
MKFS_OPTIONS -- -F -q -O quota,project /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
Can you send me the out.bad and full files for that test?
Hmm... maybe this is another one of these "it fails if a non-standard
mke2fs.conf is used, although I don't see how."
> generic/{633,697,696} fails with:
>
> --- /run/fstests/bin/tests/generic/697.out 2025-01-30 10:00:16.953276275 -0800
> +++ /var/tmp/fstests/generic/697.out.bad 2025-04-16 15:54:39.173837150 -0700
> @@ -1,2 +1,4 @@
> QA output created by 697
> +utils.c: 928: openat_tmpfile_supported - Invalid argument - failure: create
> +utils.c: 928: openat_tmpfile_supported - Invalid argument - failure: create
> Silence is golden
>
> No idea what that's about.
I don't have any idea either. I assume there's nothing in the dmesg
for that test? Those tests are passing for me, so I got nothing.
- Ted
next prev parent reply other threads:[~2025-04-17 18:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 17:56 ext4 v6.15-rc2 baseline Luis Chamberlain
2025-04-16 23:34 ` Theodore Ts'o
2025-04-17 16:38 ` Darrick J. Wong
2025-04-17 18:37 ` Theodore Ts'o [this message]
2025-04-17 20:56 ` Luis Chamberlain
2025-04-19 18:22 ` Theodore Ts'o
2025-04-21 15:54 ` Darrick J. Wong
2025-04-21 16:29 ` Theodore Ts'o
2025-04-21 16:47 ` Darrick J. Wong
2025-04-17 16:49 ` Theodore Ts'o
2025-04-17 20:35 ` Luis Chamberlain
2025-04-18 1:42 ` Luis Chamberlain
2025-04-18 3:56 ` Theodore Ts'o
2025-04-18 19:08 ` Luis Chamberlain
2025-04-19 18:36 ` Theodore Ts'o
2025-04-20 3:39 ` Theodore Ts'o
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=20250417183711.GB6008@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=dave@stgolabs.net \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=kdevops@lists.linux.dev \
--cc=linux-ext4@vger.kernel.org \
--cc=mcgrof@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