* [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
@ 2025-02-23 12:27 Zorro Lang
2025-02-23 19:30 ` Darrick J. Wong
2025-02-28 12:33 ` David Sterba
0 siblings, 2 replies; 23+ messages in thread
From: Zorro Lang @ 2025-02-23 12:27 UTC (permalink / raw)
To: fstests
[-- Attachment #1: Type: text/plain, Size: 6885 bytes --]
Hi all,
The for-next branch of the xfstests repository at:
git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
has just been updated and tagged as v2025.02.23 release.
Release Notes:
1) There's not new test cases in this release, this's a release for bug fixes
particularly.
2) Reiserfs part is removed from fstests.
3) ltp/growfiles is removed too, I think no one needs it.
I can't list all updates at here, more details please refer to below.
Thanks for all these contributions!
Thanks,
Zorro
The new head of the for-next branch is commit:
5b56a2d88819 fstests: remove reiserfs support
New commits:
Christoph Hellwig (1):
[04d0cf3f8909] generic/370: don't exclude XFS
Darrick J. Wong (35):
[cc379f50f3bd] generic/476: fix fsstress process management
[ab459c67c5e0] metadump: make non-local function variables more obvious
[f428edcec2a2] metadump: fix cleanup for v1 metadump testing
[e68a92376165] generic/019: don't fail if fio crashes while shutting down
[48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
[543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
[777732b27e62] common/dump: don't replace pids arbitrarily
[81f28acda2f2] common/populate: correct the parent pointer name creation formulae
[9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
[241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
[77548e6066fd] common/rc: create a wrapper for the su command
[ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
[c71349150d34] common/rc: hoist pkill to a helper function
[91d2880aa029] tools: add a Makefile
[88d60f434bd9] common: fix pkill by running test program in a separate session
[247ab01fa227] check: run tests in a private pid/mount namespace
[949bdf8eae31] check: deprecate using process sessions to isolate test instances
[af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
[f43da58ef936] unmount: resume logging of stdout and stderr for filtering
[5dc27fd20f80] mkfs: don't hardcode log size
[dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
[9505d04b8073] preamble: fix missing _kill_fsstress
[4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
[1bb15a27573e] generic/032: fix pinned mount failure
[b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
[040e74c89192] fuzzy: don't use readarray for xfsfind output
[0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
[336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
[96d29207c126] fix _require_scratch_duperemove ordering
[a8268531ca8b] fsstress: fix a memory leak
[e8e29e028faa] fsx: fix leaked log file pointer
[4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
[c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
[1c67e8b191fe] config: add FSX_PROG variable
[a553e7eba1cf] build: initialize stack variables to zero by default
David Sterba (2):
[9049250b4042] fstests: remove ltp/growfiles
[5b56a2d88819] fstests: remove reiserfs support
Filipe Manana (2):
[7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
[535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
Jeff Layton (1):
[bd6e01c81e21] generic/126: run it inside its own subdirectory
Code Diffstat:
.gitignore | 1 -
Makefile | 2 +-
check | 91 +-
common/config | 12 +-
common/dump | 1 -
common/fuzzy | 104 +-
common/metadump | 42 +-
common/populate | 13 +-
common/preamble | 2 +-
common/quota | 6 +-
common/rc | 146 ++-
common/reflink | 2 +-
configure.ac | 1 +
include/builddefs.in | 3 +-
lib/tlibio.c | 2 +-
ltp/Makefile | 2 +-
ltp/fsstress.c | 1 +
ltp/fsx.c | 8 +-
ltp/growfiles.c | 2607 -------------------------------------------------
m4/package_libcdev.m4 | 14 +
src/nsexec.c | 18 +-
src/xfsfind.c | 14 +-
tests/btrfs/254 | 8 +-
tests/generic/019 | 2 +-
tests/generic/032 | 9 +
tests/generic/050 | 2 +-
tests/generic/075 | 2 +-
tests/generic/085 | 2 +-
tests/generic/093 | 2 +-
tests/generic/112 | 2 +-
tests/generic/125 | 2 +-
tests/generic/126 | 17 +-
tests/generic/127 | 16 +-
tests/generic/128 | 2 +-
tests/generic/193 | 36 +-
tests/generic/230 | 14 +-
tests/generic/231 | 4 +-
tests/generic/233 | 2 +-
tests/generic/270 | 12 +-
tests/generic/310 | 6 +-
tests/generic/314 | 2 +-
tests/generic/327 | 2 +-
tests/generic/328 | 4 +-
tests/generic/355 | 2 +-
tests/generic/361 | 4 +-
tests/generic/370 | 10 +-
tests/generic/453 | 6 +-
tests/generic/455 | 2 +-
tests/generic/456 | 2 +-
tests/generic/457 | 2 +-
tests/generic/469 | 2 +-
tests/generic/476 | 4 +-
tests/generic/499 | 2 +-
tests/generic/504 | 15 +-
tests/generic/511 | 2 +-
tests/generic/514 | 2 +-
tests/generic/530 | 6 +-
tests/generic/531 | 6 +-
tests/generic/561 | 2 +-
tests/generic/573 | 2 +-
tests/generic/590 | 2 +-
tests/generic/600 | 2 +-
tests/generic/601 | 2 +-
tests/generic/603 | 10 +-
tests/generic/642 | 2 +-
tests/generic/650 | 6 +-
tests/generic/673 | 2 +-
tests/generic/674 | 2 +-
tests/generic/675 | 2 +-
tests/generic/680 | 2 +-
tests/generic/681 | 2 +-
tests/generic/682 | 2 +-
tests/generic/683 | 2 +-
tests/generic/684 | 2 +-
tests/generic/685 | 2 +-
tests/generic/686 | 2 +-
tests/generic/687 | 2 +-
tests/generic/688 | 2 +-
tests/generic/691 | 8 +-
tests/generic/721 | 10 +-
tests/generic/726 | 2 +-
tests/generic/727 | 2 +-
tests/generic/740 | 2 +-
tests/generic/746 | 2 +-
tests/generic/750 | 2 +-
tests/generic/759 | 7 +-
tests/generic/760 | 7 +-
tests/xfs/149 | 2 +-
tests/xfs/501 | 2 +-
tests/xfs/502 | 2 +-
tests/xfs/530 | 2 +-
tests/xfs/720 | 2 +-
tests/xfs/795 | 2 +-
tests/xfs/803 | 2 +-
tools/Makefile | 21 +
tools/run_privatens | 28 +
tools/run_setsid | 22 +
97 files changed, 596 insertions(+), 2890 deletions(-)
--
Zorro Lang
zlang@kernel.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-23 12:27 Zorro Lang
@ 2025-02-23 19:30 ` Darrick J. Wong
2025-02-24 5:48 ` Zorro Lang
2025-02-28 12:33 ` David Sterba
1 sibling, 1 reply; 23+ messages in thread
From: Darrick J. Wong @ 2025-02-23 19:30 UTC (permalink / raw)
To: Zorro Lang; +Cc: fstests
On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> Hi all,
>
> The for-next branch of the xfstests repository at:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> has just been updated and tagged as v2025.02.23 release.
>
> Release Notes:
> 1) There's not new test cases in this release, this's a release for bug fixes
> particularly.
> 2) Reiserfs part is removed from fstests.
> 3) ltp/growfiles is removed too, I think no one needs it.
>
> I can't list all updates at here, more details please refer to below.
> Thanks for all these contributions!
Thanks, Zorro. I know the last few months have been rough. :/
--D
> Thanks,
> Zorro
>
> The new head of the for-next branch is commit:
>
> 5b56a2d88819 fstests: remove reiserfs support
>
> New commits:
>
> Christoph Hellwig (1):
> [04d0cf3f8909] generic/370: don't exclude XFS
>
> Darrick J. Wong (35):
> [cc379f50f3bd] generic/476: fix fsstress process management
> [ab459c67c5e0] metadump: make non-local function variables more obvious
> [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> [777732b27e62] common/dump: don't replace pids arbitrarily
> [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> [77548e6066fd] common/rc: create a wrapper for the su command
> [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> [c71349150d34] common/rc: hoist pkill to a helper function
> [91d2880aa029] tools: add a Makefile
> [88d60f434bd9] common: fix pkill by running test program in a separate session
> [247ab01fa227] check: run tests in a private pid/mount namespace
> [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> [5dc27fd20f80] mkfs: don't hardcode log size
> [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> [9505d04b8073] preamble: fix missing _kill_fsstress
> [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> [1bb15a27573e] generic/032: fix pinned mount failure
> [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> [040e74c89192] fuzzy: don't use readarray for xfsfind output
> [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> [96d29207c126] fix _require_scratch_duperemove ordering
> [a8268531ca8b] fsstress: fix a memory leak
> [e8e29e028faa] fsx: fix leaked log file pointer
> [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> [1c67e8b191fe] config: add FSX_PROG variable
> [a553e7eba1cf] build: initialize stack variables to zero by default
>
> David Sterba (2):
> [9049250b4042] fstests: remove ltp/growfiles
> [5b56a2d88819] fstests: remove reiserfs support
>
> Filipe Manana (2):
> [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
>
> Jeff Layton (1):
> [bd6e01c81e21] generic/126: run it inside its own subdirectory
>
>
> Code Diffstat:
>
> .gitignore | 1 -
> Makefile | 2 +-
> check | 91 +-
> common/config | 12 +-
> common/dump | 1 -
> common/fuzzy | 104 +-
> common/metadump | 42 +-
> common/populate | 13 +-
> common/preamble | 2 +-
> common/quota | 6 +-
> common/rc | 146 ++-
> common/reflink | 2 +-
> configure.ac | 1 +
> include/builddefs.in | 3 +-
> lib/tlibio.c | 2 +-
> ltp/Makefile | 2 +-
> ltp/fsstress.c | 1 +
> ltp/fsx.c | 8 +-
> ltp/growfiles.c | 2607 -------------------------------------------------
> m4/package_libcdev.m4 | 14 +
> src/nsexec.c | 18 +-
> src/xfsfind.c | 14 +-
> tests/btrfs/254 | 8 +-
> tests/generic/019 | 2 +-
> tests/generic/032 | 9 +
> tests/generic/050 | 2 +-
> tests/generic/075 | 2 +-
> tests/generic/085 | 2 +-
> tests/generic/093 | 2 +-
> tests/generic/112 | 2 +-
> tests/generic/125 | 2 +-
> tests/generic/126 | 17 +-
> tests/generic/127 | 16 +-
> tests/generic/128 | 2 +-
> tests/generic/193 | 36 +-
> tests/generic/230 | 14 +-
> tests/generic/231 | 4 +-
> tests/generic/233 | 2 +-
> tests/generic/270 | 12 +-
> tests/generic/310 | 6 +-
> tests/generic/314 | 2 +-
> tests/generic/327 | 2 +-
> tests/generic/328 | 4 +-
> tests/generic/355 | 2 +-
> tests/generic/361 | 4 +-
> tests/generic/370 | 10 +-
> tests/generic/453 | 6 +-
> tests/generic/455 | 2 +-
> tests/generic/456 | 2 +-
> tests/generic/457 | 2 +-
> tests/generic/469 | 2 +-
> tests/generic/476 | 4 +-
> tests/generic/499 | 2 +-
> tests/generic/504 | 15 +-
> tests/generic/511 | 2 +-
> tests/generic/514 | 2 +-
> tests/generic/530 | 6 +-
> tests/generic/531 | 6 +-
> tests/generic/561 | 2 +-
> tests/generic/573 | 2 +-
> tests/generic/590 | 2 +-
> tests/generic/600 | 2 +-
> tests/generic/601 | 2 +-
> tests/generic/603 | 10 +-
> tests/generic/642 | 2 +-
> tests/generic/650 | 6 +-
> tests/generic/673 | 2 +-
> tests/generic/674 | 2 +-
> tests/generic/675 | 2 +-
> tests/generic/680 | 2 +-
> tests/generic/681 | 2 +-
> tests/generic/682 | 2 +-
> tests/generic/683 | 2 +-
> tests/generic/684 | 2 +-
> tests/generic/685 | 2 +-
> tests/generic/686 | 2 +-
> tests/generic/687 | 2 +-
> tests/generic/688 | 2 +-
> tests/generic/691 | 8 +-
> tests/generic/721 | 10 +-
> tests/generic/726 | 2 +-
> tests/generic/727 | 2 +-
> tests/generic/740 | 2 +-
> tests/generic/746 | 2 +-
> tests/generic/750 | 2 +-
> tests/generic/759 | 7 +-
> tests/generic/760 | 7 +-
> tests/xfs/149 | 2 +-
> tests/xfs/501 | 2 +-
> tests/xfs/502 | 2 +-
> tests/xfs/530 | 2 +-
> tests/xfs/720 | 2 +-
> tests/xfs/795 | 2 +-
> tests/xfs/803 | 2 +-
> tools/Makefile | 21 +
> tools/run_privatens | 28 +
> tools/run_setsid | 22 +
> 97 files changed, 596 insertions(+), 2890 deletions(-)
> --
> Zorro Lang
> zlang@kernel.org
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-23 19:30 ` Darrick J. Wong
@ 2025-02-24 5:48 ` Zorro Lang
2025-02-24 22:04 ` Dave Chinner
0 siblings, 1 reply; 23+ messages in thread
From: Zorro Lang @ 2025-02-24 5:48 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Zorro Lang, fstests
On Sun, Feb 23, 2025 at 11:30:40AM -0800, Darrick J. Wong wrote:
> On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
>
> Thanks, Zorro. I know the last few months have been rough. :/
Thank *you* help a lot, and always be patiented to take review points to
your patchset, finally we got these patches in :)
Next, I'm going to deal with your 10 PRs (73 patches), and another patchset
about the check-parallel ([PATCH 0/5]: CLI and feature improvements for
check-parallel). Will talk details with you after my testing.
I've pushed back the reviewing for some patches, now we can move on. Please
feel free to remind me if I missed anyone's patch long time :)
Thanks,
Zorro
>
> --D
>
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> > [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> > [5dc27fd20f80] mkfs: don't hardcode log size
> > [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> > [9505d04b8073] preamble: fix missing _kill_fsstress
> > [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> > [1bb15a27573e] generic/032: fix pinned mount failure
> > [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> > [040e74c89192] fuzzy: don't use readarray for xfsfind output
> > [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> > [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> > [96d29207c126] fix _require_scratch_duperemove ordering
> > [a8268531ca8b] fsstress: fix a memory leak
> > [e8e29e028faa] fsx: fix leaked log file pointer
> > [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> > [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> > [1c67e8b191fe] config: add FSX_PROG variable
> > [a553e7eba1cf] build: initialize stack variables to zero by default
> >
> > David Sterba (2):
> > [9049250b4042] fstests: remove ltp/growfiles
> > [5b56a2d88819] fstests: remove reiserfs support
> >
> > Filipe Manana (2):
> > [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> > [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
> >
> > Jeff Layton (1):
> > [bd6e01c81e21] generic/126: run it inside its own subdirectory
> >
> >
> > Code Diffstat:
> >
> > .gitignore | 1 -
> > Makefile | 2 +-
> > check | 91 +-
> > common/config | 12 +-
> > common/dump | 1 -
> > common/fuzzy | 104 +-
> > common/metadump | 42 +-
> > common/populate | 13 +-
> > common/preamble | 2 +-
> > common/quota | 6 +-
> > common/rc | 146 ++-
> > common/reflink | 2 +-
> > configure.ac | 1 +
> > include/builddefs.in | 3 +-
> > lib/tlibio.c | 2 +-
> > ltp/Makefile | 2 +-
> > ltp/fsstress.c | 1 +
> > ltp/fsx.c | 8 +-
> > ltp/growfiles.c | 2607 -------------------------------------------------
> > m4/package_libcdev.m4 | 14 +
> > src/nsexec.c | 18 +-
> > src/xfsfind.c | 14 +-
> > tests/btrfs/254 | 8 +-
> > tests/generic/019 | 2 +-
> > tests/generic/032 | 9 +
> > tests/generic/050 | 2 +-
> > tests/generic/075 | 2 +-
> > tests/generic/085 | 2 +-
> > tests/generic/093 | 2 +-
> > tests/generic/112 | 2 +-
> > tests/generic/125 | 2 +-
> > tests/generic/126 | 17 +-
> > tests/generic/127 | 16 +-
> > tests/generic/128 | 2 +-
> > tests/generic/193 | 36 +-
> > tests/generic/230 | 14 +-
> > tests/generic/231 | 4 +-
> > tests/generic/233 | 2 +-
> > tests/generic/270 | 12 +-
> > tests/generic/310 | 6 +-
> > tests/generic/314 | 2 +-
> > tests/generic/327 | 2 +-
> > tests/generic/328 | 4 +-
> > tests/generic/355 | 2 +-
> > tests/generic/361 | 4 +-
> > tests/generic/370 | 10 +-
> > tests/generic/453 | 6 +-
> > tests/generic/455 | 2 +-
> > tests/generic/456 | 2 +-
> > tests/generic/457 | 2 +-
> > tests/generic/469 | 2 +-
> > tests/generic/476 | 4 +-
> > tests/generic/499 | 2 +-
> > tests/generic/504 | 15 +-
> > tests/generic/511 | 2 +-
> > tests/generic/514 | 2 +-
> > tests/generic/530 | 6 +-
> > tests/generic/531 | 6 +-
> > tests/generic/561 | 2 +-
> > tests/generic/573 | 2 +-
> > tests/generic/590 | 2 +-
> > tests/generic/600 | 2 +-
> > tests/generic/601 | 2 +-
> > tests/generic/603 | 10 +-
> > tests/generic/642 | 2 +-
> > tests/generic/650 | 6 +-
> > tests/generic/673 | 2 +-
> > tests/generic/674 | 2 +-
> > tests/generic/675 | 2 +-
> > tests/generic/680 | 2 +-
> > tests/generic/681 | 2 +-
> > tests/generic/682 | 2 +-
> > tests/generic/683 | 2 +-
> > tests/generic/684 | 2 +-
> > tests/generic/685 | 2 +-
> > tests/generic/686 | 2 +-
> > tests/generic/687 | 2 +-
> > tests/generic/688 | 2 +-
> > tests/generic/691 | 8 +-
> > tests/generic/721 | 10 +-
> > tests/generic/726 | 2 +-
> > tests/generic/727 | 2 +-
> > tests/generic/740 | 2 +-
> > tests/generic/746 | 2 +-
> > tests/generic/750 | 2 +-
> > tests/generic/759 | 7 +-
> > tests/generic/760 | 7 +-
> > tests/xfs/149 | 2 +-
> > tests/xfs/501 | 2 +-
> > tests/xfs/502 | 2 +-
> > tests/xfs/530 | 2 +-
> > tests/xfs/720 | 2 +-
> > tests/xfs/795 | 2 +-
> > tests/xfs/803 | 2 +-
> > tools/Makefile | 21 +
> > tools/run_privatens | 28 +
> > tools/run_setsid | 22 +
> > 97 files changed, 596 insertions(+), 2890 deletions(-)
> > --
> > Zorro Lang
> > zlang@kernel.org
>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-24 5:48 ` Zorro Lang
@ 2025-02-24 22:04 ` Dave Chinner
2025-02-25 9:00 ` Zorro Lang
0 siblings, 1 reply; 23+ messages in thread
From: Dave Chinner @ 2025-02-24 22:04 UTC (permalink / raw)
To: Zorro Lang; +Cc: Darrick J. Wong, Zorro Lang, fstests
On Mon, Feb 24, 2025 at 01:48:39PM +0800, Zorro Lang wrote:
> On Sun, Feb 23, 2025 at 11:30:40AM -0800, Darrick J. Wong wrote:
> > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > Hi all,
> > >
> > > The for-next branch of the xfstests repository at:
> > >
> > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > >
> > > has just been updated and tagged as v2025.02.23 release.
> > >
> > > Release Notes:
> > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > particularly.
> > > 2) Reiserfs part is removed from fstests.
> > > 3) ltp/growfiles is removed too, I think no one needs it.
> > >
> > > I can't list all updates at here, more details please refer to below.
> > > Thanks for all these contributions!
> >
> > Thanks, Zorro. I know the last few months have been rough. :/
>
> Thank *you* help a lot, and always be patiented to take review points to
> your patchset, finally we got these patches in :)
>
> Next, I'm going to deal with your 10 PRs (73 patches), and another patchset
> about the check-parallel ([PATCH 0/5]: CLI and feature improvements for
> check-parallel). Will talk details with you after my testing.
No, please do not pull those check-parallel patches or waste time
trying to apply/review them right now. I have rebased and updated
versions locally that I'm getting ready to send out - this has been
waiting on Darrick's namespace helper fixes to land so I can test
things with those patches in place...
-Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-24 22:04 ` Dave Chinner
@ 2025-02-25 9:00 ` Zorro Lang
0 siblings, 0 replies; 23+ messages in thread
From: Zorro Lang @ 2025-02-25 9:00 UTC (permalink / raw)
To: Dave Chinner; +Cc: Darrick J. Wong, Zorro Lang, fstests
On Tue, Feb 25, 2025 at 09:04:25AM +1100, Dave Chinner wrote:
> On Mon, Feb 24, 2025 at 01:48:39PM +0800, Zorro Lang wrote:
> > On Sun, Feb 23, 2025 at 11:30:40AM -0800, Darrick J. Wong wrote:
> > > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > > Hi all,
> > > >
> > > > The for-next branch of the xfstests repository at:
> > > >
> > > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > > >
> > > > has just been updated and tagged as v2025.02.23 release.
> > > >
> > > > Release Notes:
> > > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > > particularly.
> > > > 2) Reiserfs part is removed from fstests.
> > > > 3) ltp/growfiles is removed too, I think no one needs it.
> > > >
> > > > I can't list all updates at here, more details please refer to below.
> > > > Thanks for all these contributions!
> > >
> > > Thanks, Zorro. I know the last few months have been rough. :/
> >
> > Thank *you* help a lot, and always be patiented to take review points to
> > your patchset, finally we got these patches in :)
> >
> > Next, I'm going to deal with your 10 PRs (73 patches), and another patchset
> > about the check-parallel ([PATCH 0/5]: CLI and feature improvements for
> > check-parallel). Will talk details with you after my testing.
>
> No, please do not pull those check-parallel patches or waste time
> trying to apply/review them right now. I have rebased and updated
> versions locally that I'm getting ready to send out - this has been
> waiting on Darrick's namespace helper fixes to land so I can test
> things with those patches in place...
Thanks Dave, I knew Darrick is working on namespace helpers, I was on a travel
at that time, so we haven't gotten time to talk about the details, good to know
your plan :)
So now I'll try to check and merge the 10 PRs from Darrick at first, then the
namespace helpers maybe next. Feel free to let us know your review points and
plans.
Thanks,
Zorro
>
> -Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
[not found] <67bb1448.500a0220.af3ac.9928SMTPIN_ADDED_BROKEN@mx.google.com>
@ 2025-02-27 13:32 ` Filipe Manana
2025-02-27 17:52 ` Darrick J. Wong
2025-03-01 17:22 ` Zorro Lang
0 siblings, 2 replies; 23+ messages in thread
From: Filipe Manana @ 2025-02-27 13:32 UTC (permalink / raw)
To: Zorro Lang; +Cc: fstests, linux-btrfs, Darrick J. Wong
On Sun, Feb 23, 2025 at 12:27 PM Zorro Lang <zlang@kernel.org> wrote:
>
> Hi all,
>
> The for-next branch of the xfstests repository at:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> has just been updated and tagged as v2025.02.23 release.
>
> Release Notes:
> 1) There's not new test cases in this release, this's a release for bug fixes
> particularly.
> 2) Reiserfs part is removed from fstests.
> 3) ltp/growfiles is removed too, I think no one needs it.
>
> I can't list all updates at here, more details please refer to below.
> Thanks for all these contributions!
>
> Thanks,
> Zorro
>
> The new head of the for-next branch is commit:
>
> 5b56a2d88819 fstests: remove reiserfs support
>
> New commits:
>
> Christoph Hellwig (1):
> [04d0cf3f8909] generic/370: don't exclude XFS
>
> Darrick J. Wong (35):
> [cc379f50f3bd] generic/476: fix fsstress process management
> [ab459c67c5e0] metadump: make non-local function variables more obvious
> [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> [777732b27e62] common/dump: don't replace pids arbitrarily
> [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> [77548e6066fd] common/rc: create a wrapper for the su command
> [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> [c71349150d34] common/rc: hoist pkill to a helper function
> [91d2880aa029] tools: add a Makefile
> [88d60f434bd9] common: fix pkill by running test program in a separate session
> [247ab01fa227] check: run tests in a private pid/mount namespace
By the way, this commits breaks several btrfs test cases in the
read_repair group:
$ ./check -g read_repair
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/140 1s ... [failed, exit status 1]- output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad)
--- tests/btrfs/140.out 2024-06-04 12:18:50.080308741 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad
2025-02-27 13:27:56.050933812 +0000
@@ -1,3 +1,5 @@
QA output created by 140
wrote 131072/131072 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+repair failed, csums don't match
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/140.full for details)
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
/home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad' to see
the entire diff)
btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
--- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
2025-02-27 13:27:57.233352695 +0000
@@ -1,3 +1,5 @@
QA output created by 141
wrote 131072/131072 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+repair failed, csums don't match
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/141.full for details)
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/141.out
/home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad' to see
the entire diff)
btrfs/142 1s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad)
--- tests/btrfs/142.out 2020-06-10 19:29:03.818519162 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad
2025-02-27 13:27:59.133249259 +0000
@@ -1,37 +1,37 @@
QA output created by 142
wrote 131072/131072 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/142.out
/home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad' to see
the entire diff)
btrfs/143 1s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad)
--- tests/btrfs/143.out 2020-06-10 19:29:03.818519162 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad
2025-02-27 13:28:00.989680223 +0000
@@ -1,37 +1,37 @@
QA output created by 143
wrote 131072/131072 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/143.out
/home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad' to see
the entire diff)
btrfs/150 1s ... 1s
btrfs/157 2s ... 1s
btrfs/215 1s ... 1s
btrfs/265 2s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
--- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
2025-02-27 13:28:05.589305927 +0000
@@ -5,71 +5,71 @@
step 2......corrupt file extent
step 3......repair the bad copy
step 4......check if the repair worked
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
the entire diff)
btrfs/266 3s ... 2s
btrfs/267 2s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad)
--- tests/btrfs/267.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad
2025-02-27 13:28:09.161394788 +0000
@@ -73,37 +73,37 @@
XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
read 512/512 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/267.out
/home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad' to see
the entire diff)
btrfs/268 3s ... 2s
btrfs/269 2s ... 1s
btrfs/270 1s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad)
--- tests/btrfs/270.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad
2025-02-27 13:28:14.090153054 +0000
@@ -5,3 +5,4099 @@
step 2......corrupt file extent
step 3......repair the bad copy
step 4......check if the repair worked
+ 1 170 x 273 M-;
+ 2 136 ^ 273 M-;
+ 3 354 M-l 273 M-;
+ 4 320 M-P 273 M-;
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/270.out
/home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad' to see
the entire diff)
Ran: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/150 btrfs/157
btrfs/215 btrfs/265 btrfs/266 btrfs/267 btrfs/268 btrfs/269 btrfs/270
Failures: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/265 btrfs/267 btrfs/270
Failed 7 of 13 tests
The failures seems to be timing sensitive, as running a test
individually doesn't always fails, for example:
$ root 13:30:43 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/265 1s ... 2s
Ran: btrfs/265
Passed all 1 tests
root 13:30:46 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/265 2s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
--- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
2025-02-27 13:30:49.386584060 +0000
@@ -5,71 +5,71 @@
step 2......corrupt file extent
step 3......repair the bad copy
step 4......check if the repair worked
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
the entire diff)
Ran: btrfs/265
Failures: btrfs/265
Failed 1 of 1 tests
root 13:30:49 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/265 2s ... 1s
Ran: btrfs/265
Passed all 1 tests
root 13:31:02 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/265 1s ... - output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
--- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
2025-02-27 13:31:05.522911416 +0000
@@ -5,38 +5,38 @@
step 2......corrupt file extent
step 3......repair the bad copy
step 4......check if the repair worked
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
................
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
/home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
the entire diff)
Ran: btrfs/265
Failures: btrfs/265
Failed 1 of 1 tests
root 13:31:05 /home/fdmanana/git/hub/xfstests >
Bisection using 100 iterations reliably points to that commit.
Any ideas Darrick?
Thanks.
> [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> [5dc27fd20f80] mkfs: don't hardcode log size
> [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> [9505d04b8073] preamble: fix missing _kill_fsstress
> [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> [1bb15a27573e] generic/032: fix pinned mount failure
> [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> [040e74c89192] fuzzy: don't use readarray for xfsfind output
> [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> [96d29207c126] fix _require_scratch_duperemove ordering
> [a8268531ca8b] fsstress: fix a memory leak
> [e8e29e028faa] fsx: fix leaked log file pointer
> [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> [1c67e8b191fe] config: add FSX_PROG variable
> [a553e7eba1cf] build: initialize stack variables to zero by default
>
> David Sterba (2):
> [9049250b4042] fstests: remove ltp/growfiles
> [5b56a2d88819] fstests: remove reiserfs support
>
> Filipe Manana (2):
> [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
>
> Jeff Layton (1):
> [bd6e01c81e21] generic/126: run it inside its own subdirectory
>
>
> Code Diffstat:
>
> .gitignore | 1 -
> Makefile | 2 +-
> check | 91 +-
> common/config | 12 +-
> common/dump | 1 -
> common/fuzzy | 104 +-
> common/metadump | 42 +-
> common/populate | 13 +-
> common/preamble | 2 +-
> common/quota | 6 +-
> common/rc | 146 ++-
> common/reflink | 2 +-
> configure.ac | 1 +
> include/builddefs.in | 3 +-
> lib/tlibio.c | 2 +-
> ltp/Makefile | 2 +-
> ltp/fsstress.c | 1 +
> ltp/fsx.c | 8 +-
> ltp/growfiles.c | 2607 -------------------------------------------------
> m4/package_libcdev.m4 | 14 +
> src/nsexec.c | 18 +-
> src/xfsfind.c | 14 +-
> tests/btrfs/254 | 8 +-
> tests/generic/019 | 2 +-
> tests/generic/032 | 9 +
> tests/generic/050 | 2 +-
> tests/generic/075 | 2 +-
> tests/generic/085 | 2 +-
> tests/generic/093 | 2 +-
> tests/generic/112 | 2 +-
> tests/generic/125 | 2 +-
> tests/generic/126 | 17 +-
> tests/generic/127 | 16 +-
> tests/generic/128 | 2 +-
> tests/generic/193 | 36 +-
> tests/generic/230 | 14 +-
> tests/generic/231 | 4 +-
> tests/generic/233 | 2 +-
> tests/generic/270 | 12 +-
> tests/generic/310 | 6 +-
> tests/generic/314 | 2 +-
> tests/generic/327 | 2 +-
> tests/generic/328 | 4 +-
> tests/generic/355 | 2 +-
> tests/generic/361 | 4 +-
> tests/generic/370 | 10 +-
> tests/generic/453 | 6 +-
> tests/generic/455 | 2 +-
> tests/generic/456 | 2 +-
> tests/generic/457 | 2 +-
> tests/generic/469 | 2 +-
> tests/generic/476 | 4 +-
> tests/generic/499 | 2 +-
> tests/generic/504 | 15 +-
> tests/generic/511 | 2 +-
> tests/generic/514 | 2 +-
> tests/generic/530 | 6 +-
> tests/generic/531 | 6 +-
> tests/generic/561 | 2 +-
> tests/generic/573 | 2 +-
> tests/generic/590 | 2 +-
> tests/generic/600 | 2 +-
> tests/generic/601 | 2 +-
> tests/generic/603 | 10 +-
> tests/generic/642 | 2 +-
> tests/generic/650 | 6 +-
> tests/generic/673 | 2 +-
> tests/generic/674 | 2 +-
> tests/generic/675 | 2 +-
> tests/generic/680 | 2 +-
> tests/generic/681 | 2 +-
> tests/generic/682 | 2 +-
> tests/generic/683 | 2 +-
> tests/generic/684 | 2 +-
> tests/generic/685 | 2 +-
> tests/generic/686 | 2 +-
> tests/generic/687 | 2 +-
> tests/generic/688 | 2 +-
> tests/generic/691 | 8 +-
> tests/generic/721 | 10 +-
> tests/generic/726 | 2 +-
> tests/generic/727 | 2 +-
> tests/generic/740 | 2 +-
> tests/generic/746 | 2 +-
> tests/generic/750 | 2 +-
> tests/generic/759 | 7 +-
> tests/generic/760 | 7 +-
> tests/xfs/149 | 2 +-
> tests/xfs/501 | 2 +-
> tests/xfs/502 | 2 +-
> tests/xfs/530 | 2 +-
> tests/xfs/720 | 2 +-
> tests/xfs/795 | 2 +-
> tests/xfs/803 | 2 +-
> tools/Makefile | 21 +
> tools/run_privatens | 28 +
> tools/run_setsid | 22 +
> 97 files changed, 596 insertions(+), 2890 deletions(-)
> --
> Zorro Lang
> zlang@kernel.org
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-27 13:32 ` [ANNOUNCE] fstests: for-next branch updated to v2025.02.23 Filipe Manana
@ 2025-02-27 17:52 ` Darrick J. Wong
2025-02-28 11:54 ` David Sterba
2025-03-01 17:22 ` Zorro Lang
1 sibling, 1 reply; 23+ messages in thread
From: Darrick J. Wong @ 2025-02-27 17:52 UTC (permalink / raw)
To: Filipe Manana; +Cc: Zorro Lang, fstests, linux-btrfs
On Thu, Feb 27, 2025 at 01:32:42PM +0000, Filipe Manana wrote:
> On Sun, Feb 23, 2025 at 12:27 PM Zorro Lang <zlang@kernel.org> wrote:
> >
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
> >
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
>
> By the way, this commits breaks several btrfs test cases in the
> read_repair group:
>
> $ ./check -g read_repair
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/140 1s ... [failed, exit status 1]- output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad)
> --- tests/btrfs/140.out 2024-06-04 12:18:50.080308741 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad
> 2025-02-27 13:27:56.050933812 +0000
> @@ -1,3 +1,5 @@
> QA output created by 140
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +repair failed, csums don't match
> +(see /home/fdmanana/git/hub/xfstests/results//btrfs/140.full for details)
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad' to see
> the entire diff)
> btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
> --- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
...which I never saw because I don't have SCRATCH_DEV_POOL set up. :(
I traced it to this code:
while [[ -z $( (( BASHPID % nr_mirrors == mirror )) &&
exec $XFS_IO_PROG \
-c "pread -b $size $offset $size" $file) ]]; do
:
done
If memory serves, btrfs' raid rotoring is based on the global pid
number, right? If so, then this is broken with the new run_privatens
isolation (i.e. the commit you referenced) because the pids that the
test program sees are private to that namespace.
IOWS, the subprocesses created in the loop test might appear to have
pids 3 -> 4 -> 5, but those could very well be 100, 200, 300 in the
global namespace, in which case all reads go to the same mirror
(assuming nr_mirrors==2 as it does in btrfs/140).
A really shitty hack around that is this:
for ((i = 0; i < (nr_mirrors * 4); i++)); do
$XFS_IO_PROG -c "pread -b $size $offset $size" $file
done >> $seqres.full
but now we're just hoping that reading 8x actually manages to hit both
mirrors at some point in this test. But that doesn't work reliably in
btrfs/141 even if I turn it up from 4 to 11.
Is there *any* other way to trigger read from a specific mirror?
--D
> 2025-02-27 13:27:57.233352695 +0000
> @@ -1,3 +1,5 @@
> QA output created by 141
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +repair failed, csums don't match
> +(see /home/fdmanana/git/hub/xfstests/results//btrfs/141.full for details)
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/141.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad' to see
> the entire diff)
> btrfs/142 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad)
> --- tests/btrfs/142.out 2020-06-10 19:29:03.818519162 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad
> 2025-02-27 13:27:59.133249259 +0000
> @@ -1,37 +1,37 @@
> QA output created by 142
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/142.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad' to see
> the entire diff)
> btrfs/143 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad)
> --- tests/btrfs/143.out 2020-06-10 19:29:03.818519162 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad
> 2025-02-27 13:28:00.989680223 +0000
> @@ -1,37 +1,37 @@
> QA output created by 143
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/143.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad' to see
> the entire diff)
> btrfs/150 1s ... 1s
> btrfs/157 2s ... 1s
> btrfs/215 1s ... 1s
> btrfs/265 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:28:05.589305927 +0000
> @@ -5,71 +5,71 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> btrfs/266 3s ... 2s
> btrfs/267 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad)
> --- tests/btrfs/267.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad
> 2025-02-27 13:28:09.161394788 +0000
> @@ -73,37 +73,37 @@
> XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> read 512/512 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/267.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad' to see
> the entire diff)
> btrfs/268 3s ... 2s
> btrfs/269 2s ... 1s
> btrfs/270 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad)
> --- tests/btrfs/270.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad
> 2025-02-27 13:28:14.090153054 +0000
> @@ -5,3 +5,4099 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> + 1 170 x 273 M-;
> + 2 136 ^ 273 M-;
> + 3 354 M-l 273 M-;
> + 4 320 M-P 273 M-;
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/270.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad' to see
> the entire diff)
> Ran: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/150 btrfs/157
> btrfs/215 btrfs/265 btrfs/266 btrfs/267 btrfs/268 btrfs/269 btrfs/270
> Failures: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/265 btrfs/267 btrfs/270
> Failed 7 of 13 tests
>
> The failures seems to be timing sensitive, as running a test
> individually doesn't always fails, for example:
>
> $ root 13:30:43 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 1s ... 2s
> Ran: btrfs/265
> Passed all 1 tests
>
> root 13:30:46 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:30:49.386584060 +0000
> @@ -5,71 +5,71 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> Ran: btrfs/265
> Failures: btrfs/265
> Failed 1 of 1 tests
>
> root 13:30:49 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 2s ... 1s
> Ran: btrfs/265
> Passed all 1 tests
>
> root 13:31:02 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:31:05.522911416 +0000
> @@ -5,38 +5,38 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> Ran: btrfs/265
> Failures: btrfs/265
> Failed 1 of 1 tests
>
> root 13:31:05 /home/fdmanana/git/hub/xfstests >
>
> Bisection using 100 iterations reliably points to that commit.
>
> Any ideas Darrick?
>
> Thanks.
>
>
>
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> > [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> > [5dc27fd20f80] mkfs: don't hardcode log size
> > [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> > [9505d04b8073] preamble: fix missing _kill_fsstress
> > [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> > [1bb15a27573e] generic/032: fix pinned mount failure
> > [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> > [040e74c89192] fuzzy: don't use readarray for xfsfind output
> > [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> > [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> > [96d29207c126] fix _require_scratch_duperemove ordering
> > [a8268531ca8b] fsstress: fix a memory leak
> > [e8e29e028faa] fsx: fix leaked log file pointer
> > [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> > [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> > [1c67e8b191fe] config: add FSX_PROG variable
> > [a553e7eba1cf] build: initialize stack variables to zero by default
> >
> > David Sterba (2):
> > [9049250b4042] fstests: remove ltp/growfiles
> > [5b56a2d88819] fstests: remove reiserfs support
> >
> > Filipe Manana (2):
> > [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> > [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
> >
> > Jeff Layton (1):
> > [bd6e01c81e21] generic/126: run it inside its own subdirectory
> >
> >
> > Code Diffstat:
> >
> > .gitignore | 1 -
> > Makefile | 2 +-
> > check | 91 +-
> > common/config | 12 +-
> > common/dump | 1 -
> > common/fuzzy | 104 +-
> > common/metadump | 42 +-
> > common/populate | 13 +-
> > common/preamble | 2 +-
> > common/quota | 6 +-
> > common/rc | 146 ++-
> > common/reflink | 2 +-
> > configure.ac | 1 +
> > include/builddefs.in | 3 +-
> > lib/tlibio.c | 2 +-
> > ltp/Makefile | 2 +-
> > ltp/fsstress.c | 1 +
> > ltp/fsx.c | 8 +-
> > ltp/growfiles.c | 2607 -------------------------------------------------
> > m4/package_libcdev.m4 | 14 +
> > src/nsexec.c | 18 +-
> > src/xfsfind.c | 14 +-
> > tests/btrfs/254 | 8 +-
> > tests/generic/019 | 2 +-
> > tests/generic/032 | 9 +
> > tests/generic/050 | 2 +-
> > tests/generic/075 | 2 +-
> > tests/generic/085 | 2 +-
> > tests/generic/093 | 2 +-
> > tests/generic/112 | 2 +-
> > tests/generic/125 | 2 +-
> > tests/generic/126 | 17 +-
> > tests/generic/127 | 16 +-
> > tests/generic/128 | 2 +-
> > tests/generic/193 | 36 +-
> > tests/generic/230 | 14 +-
> > tests/generic/231 | 4 +-
> > tests/generic/233 | 2 +-
> > tests/generic/270 | 12 +-
> > tests/generic/310 | 6 +-
> > tests/generic/314 | 2 +-
> > tests/generic/327 | 2 +-
> > tests/generic/328 | 4 +-
> > tests/generic/355 | 2 +-
> > tests/generic/361 | 4 +-
> > tests/generic/370 | 10 +-
> > tests/generic/453 | 6 +-
> > tests/generic/455 | 2 +-
> > tests/generic/456 | 2 +-
> > tests/generic/457 | 2 +-
> > tests/generic/469 | 2 +-
> > tests/generic/476 | 4 +-
> > tests/generic/499 | 2 +-
> > tests/generic/504 | 15 +-
> > tests/generic/511 | 2 +-
> > tests/generic/514 | 2 +-
> > tests/generic/530 | 6 +-
> > tests/generic/531 | 6 +-
> > tests/generic/561 | 2 +-
> > tests/generic/573 | 2 +-
> > tests/generic/590 | 2 +-
> > tests/generic/600 | 2 +-
> > tests/generic/601 | 2 +-
> > tests/generic/603 | 10 +-
> > tests/generic/642 | 2 +-
> > tests/generic/650 | 6 +-
> > tests/generic/673 | 2 +-
> > tests/generic/674 | 2 +-
> > tests/generic/675 | 2 +-
> > tests/generic/680 | 2 +-
> > tests/generic/681 | 2 +-
> > tests/generic/682 | 2 +-
> > tests/generic/683 | 2 +-
> > tests/generic/684 | 2 +-
> > tests/generic/685 | 2 +-
> > tests/generic/686 | 2 +-
> > tests/generic/687 | 2 +-
> > tests/generic/688 | 2 +-
> > tests/generic/691 | 8 +-
> > tests/generic/721 | 10 +-
> > tests/generic/726 | 2 +-
> > tests/generic/727 | 2 +-
> > tests/generic/740 | 2 +-
> > tests/generic/746 | 2 +-
> > tests/generic/750 | 2 +-
> > tests/generic/759 | 7 +-
> > tests/generic/760 | 7 +-
> > tests/xfs/149 | 2 +-
> > tests/xfs/501 | 2 +-
> > tests/xfs/502 | 2 +-
> > tests/xfs/530 | 2 +-
> > tests/xfs/720 | 2 +-
> > tests/xfs/795 | 2 +-
> > tests/xfs/803 | 2 +-
> > tools/Makefile | 21 +
> > tools/run_privatens | 28 +
> > tools/run_setsid | 22 +
> > 97 files changed, 596 insertions(+), 2890 deletions(-)
> > --
> > Zorro Lang
> > zlang@kernel.org
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-27 17:52 ` Darrick J. Wong
@ 2025-02-28 11:54 ` David Sterba
0 siblings, 0 replies; 23+ messages in thread
From: David Sterba @ 2025-02-28 11:54 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Filipe Manana, Zorro Lang, fstests, linux-btrfs
On Thu, Feb 27, 2025 at 09:52:21AM -0800, Darrick J. Wong wrote:
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad' to see
> > the entire diff)
> > btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
> > --- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
>
> ...which I never saw because I don't have SCRATCH_DEV_POOL set up. :(
>
> I traced it to this code:
>
> while [[ -z $( (( BASHPID % nr_mirrors == mirror )) &&
> exec $XFS_IO_PROG \
> -c "pread -b $size $offset $size" $file) ]]; do
> :
> done
>
> If memory serves, btrfs' raid rotoring is based on the global pid
> number, right? If so, then this is broken with the new run_privatens
> isolation (i.e. the commit you referenced) because the pids that the
> test program sees are private to that namespace.
>
> IOWS, the subprocesses created in the loop test might appear to have
> pids 3 -> 4 -> 5, but those could very well be 100, 200, 300 in the
> global namespace, in which case all reads go to the same mirror
> (assuming nr_mirrors==2 as it does in btrfs/140).
>
> A really shitty hack around that is this:
>
> for ((i = 0; i < (nr_mirrors * 4); i++)); do
> $XFS_IO_PROG -c "pread -b $size $offset $size" $file
> done >> $seqres.full
>
> but now we're just hoping that reading 8x actually manages to hit both
> mirrors at some point in this test. But that doesn't work reliably in
> btrfs/141 even if I turn it up from 4 to 11.
>
> Is there *any* other way to trigger read from a specific mirror?
Yes, but it's still in the experimental build. There's another
algorithm to pick the mirror based on the load so we're departing from
the pid based selection in the long run.
We can skip the tests that depend on the pids which seem to be even more
unpredictable with the namespaces. This will reduce the test coverage in
non-developer builds but the test is not something critical I guess.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-23 12:27 Zorro Lang
2025-02-23 19:30 ` Darrick J. Wong
@ 2025-02-28 12:33 ` David Sterba
2025-02-28 17:33 ` Darrick J. Wong
` (2 more replies)
1 sibling, 3 replies; 23+ messages in thread
From: David Sterba @ 2025-02-28 12:33 UTC (permalink / raw)
To: Zorro Lang; +Cc: fstests
On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> Hi all,
>
> The for-next branch of the xfstests repository at:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> has just been updated and tagged as v2025.02.23 release.
>
> Release Notes:
> 1) There's not new test cases in this release, this's a release for bug fixes
> particularly.
> 2) Reiserfs part is removed from fstests.
> 3) ltp/growfiles is removed too, I think no one needs it.
>
> I can't list all updates at here, more details please refer to below.
> Thanks for all these contributions!
>
> Thanks,
> Zorro
>
> The new head of the for-next branch is commit:
>
> 5b56a2d88819 fstests: remove reiserfs support
>
> New commits:
>
> Christoph Hellwig (1):
> [04d0cf3f8909] generic/370: don't exclude XFS
>
> Darrick J. Wong (35):
> [cc379f50f3bd] generic/476: fix fsstress process management
> [ab459c67c5e0] metadump: make non-local function variables more obvious
> [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> [777732b27e62] common/dump: don't replace pids arbitrarily
> [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> [77548e6066fd] common/rc: create a wrapper for the su command
> [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> [c71349150d34] common/rc: hoist pkill to a helper function
> [91d2880aa029] tools: add a Makefile
> [88d60f434bd9] common: fix pkill by running test program in a separate session
> [247ab01fa227] check: run tests in a private pid/mount namespace
> [949bdf8eae31] check: deprecate using process sessions to isolate test instances
I'm using a setup with a minimal VM system without systemd and such and
dedicate the whole machine to one instance. I'm not interested in the
check-parallel updates and test case separation. All fine if it is
supported and lets me continue using single instance.
But as I read it and the deprecation it's not going to be the supported
use case. After last week update of fstests 100% of cases failed in the
test setup (_seq_run). My workaround is to simply disable it by
check:
HAVE_PRIVATENS=
HAVE_SYSTEMD_SCOPES=
so I don't have to debug changes to the detection of the scope and
namespaces and after each for-next update. I understand that with a
custom system setup I'm on my own but until recently things have been
fine but now after each update either test cases fail or the whole test
infrastructure does not work.
It's not just me who observes that. It seems that BTRFS is not tested
before release as thoroughly as other filesystems (probably just XFS).
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-28 12:33 ` David Sterba
@ 2025-02-28 17:33 ` Darrick J. Wong
2025-03-01 1:01 ` Theodore Ts'o
2025-03-01 14:08 ` Zorro Lang
2025-03-01 16:50 ` Zorro Lang
2 siblings, 1 reply; 23+ messages in thread
From: Darrick J. Wong @ 2025-02-28 17:33 UTC (permalink / raw)
To: David Sterba; +Cc: Zorro Lang, fstests
On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
> >
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
>
> I'm using a setup with a minimal VM system without systemd and such and
> dedicate the whole machine to one instance. I'm not interested in the
> check-parallel updates and test case separation. All fine if it is
> supported and lets me continue using single instance.
Hi Dave (Sterba),
Agreed. I would very much have liked to continue single-instance
testing in peace the same way I always have. There are things that
excite me that I would like to move onto; refactoring a large pile of
bash is NOT one of them.
Before anyone gets any ideas -- there is no grand plan or collaboration
here. Chinner posted an RFC[1] and wrote:
"This will probably take a bit of time, so I'd like to get the bug
fixes, improvements and infrastructure changes underway so I'm not
left carrying a huge patchset for months...."
[1] https://lore.kernel.org/fstests/20241127045403.3665299-1-david@fromorbit.com/
and later roared[2] at me that he isn't some n00b as a response to my
question about whether he'd had problems with xfs_scrub:
"Thank you for finding this, Darrick, but there is absolutely no need to
treat me like a n00b who doesn't know how kernel development works."
[2] https://lore.kernel.org/fstests/Z0pBKWBlXLBxwK3D@dread.disaster.area/
Yeah, I know he's a senior developer.
Apparently Zorro felt pressured into merging it to for-next over my
misgivings and the obviously inadequate testing by the author. I don't
know why he made the decision to merge it. If Zorro wants to discuss
that publicly, he can do so.
So it went in, and everything broke. Ted and Amir and I (and probably
more people) noticed and started comparing notes and complaining, but
Chinner didn't respond by trying to fix anything. Instead, he told me
to go fix the stuff his changes broke:
"Changing existing infrastructure behaviour to better suit *your* test
environments is *your* responsibility to address, not mine. I don't
care if MKFS_OPTIONS get dropped in occasional tests, it's more
important to me that the tests run fast so I can iterate my
modify-build-test development cycle faster."
[3] https://lore.kernel.org/fstests/Z2SG2HsqgA46kuAz@dread.disaster.area/
I've been told that Chinner was on vacation from mid December to mid
January. If that's true then I feel sad that someone would come back
from vacation just to talk condescendingly to me. If it's not true then
wow.
Anyway, I only took on fixing fstests so that I could push *tested* XFS
code towards cem and linus for 6.14-rc1. That was my only motivation in
adjusting the recent killall->pkill code changes. But this is bash, so
there are a lot of subtleties and (as we have all seen) a high risk of
breakage.
I'm doing this under duress. I don't want to be wrangling what used to
be well-worn bash. I don't know what Chinner's future plans are. I
don't know if he and Zorro have discussed this further. I'm only doing
this because I feel obligated to enable testing in the community.
I'm sorry that things have gotten really messed up for you and Felipe.
This whole situation is messed up. I don't want to be here.
</defensive blathering>
> But as I read it and the deprecation it's not going to be the supported
> use case. After last week update of fstests 100% of cases failed in the
> test setup (_seq_run). My workaround is to simply disable it by
>
> check:
> HAVE_PRIVATENS=
> HAVE_SYSTEMD_SCOPES=
If you don't have systemd, then HAVE_SYSTEMD_SCOPES should never be set
to "yes", correct? I'm wondering if there's a detection bug somewhere,
or are you simply overriding the upstream logic with a large hammer?
> so I don't have to debug changes to the detection of the scope and
> namespaces and after each for-next update. I understand that with a
> custom system setup I'm on my own but until recently things have been
> fine but now after each update either test cases fail or the whole test
> infrastructure does not work.
I'm willing to *undeprecate* tools/run_setsid. Clearly you have a use
case for that.
Thinking slightly further, if check-parallel is going to require
tools/run_privatens to work, then we could just revert all the pkill
changes in the test suite. That would have been a useful design
discussion to have had before merging.
> It's not just me who observes that. It seems that BTRFS is not tested
> before release as thoroughly as other filesystems (probably just XFS).
Admittedly, I only run ext4/btrfs in the default configurations. I only
learned yesterday about SCRATCH_DEV_POOL because Felipe called that out.
--D
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-28 17:33 ` Darrick J. Wong
@ 2025-03-01 1:01 ` Theodore Ts'o
0 siblings, 0 replies; 23+ messages in thread
From: Theodore Ts'o @ 2025-03-01 1:01 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: David Sterba, Zorro Lang, fstests
On Fri, Feb 28, 2025 at 09:33:19AM -0800, Darrick J. Wong wrote:
>
> Agreed. I would very much have liked to continue single-instance
> testing in peace the same way I always have. There are things that
> excite me that I would like to move onto; refactoring a large pile of
> bash is NOT one of them.
I'm also not particularly interested in check-parallel; the reason for
this is that using a 64-CPU system is *expensive*. It's actually
cheaper to kick off multiple VM's and then shard the tests across
multiple VM's. It's cheaper to use a multiple small, cheaper VM's
compared to a single large VM.
Sure, having a fast wall clock time is kinda cool. But not everyone
has access to -- or can afford -- a 64-CPU behemonth. (Either the
cost of the server, or the cost of electricity / air conditioning ---
I recently upgrading to an AMD Threadripper, although not a 64-CPU
server, since I'm not that wealthy, and was shocked to find that it
consumes 100W at *idle*.)
> Before anyone gets any ideas -- there is no grand plan or collaboration
> here. Chinner posted an RFC[1] and wrote:
>
> "This will probably take a bit of time, so I'd like to get the bug
> fixes, improvements and infrastructure changes underway so I'm not
> left carrying a huge patchset for months...."
Yeah, I'll say that I'm a bit annoyed myself, since I've been carrying
patches out of trees for *years* because Dave has objected that the
patches didn't reach his high standards, and then the cr*p that was
check-parallel got merged? Because he's an XFS architect? I can't
help but think that there is a massive double standard....
> > It's not just me who observes that. It seems that BTRFS is not tested
> > before release as thoroughly as other filesystems (probably just XFS).
>
> Admittedly, I only run ext4/btrfs in the default configurations. I only
> learned yesterday about SCRATCH_DEV_POOL because Felipe called that out.
I'm actually running ext4, xfs, btrfs, and f2fs on fs-next every day.
I used to update to xfstests's for-next quite regularly. But given
how destablized for-next got, I reduced the regularity of updating to
the latest for-next, because I got busy and I didn't always have time
to debug for-next breakages....
- Ted
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-28 12:33 ` David Sterba
2025-02-28 17:33 ` Darrick J. Wong
@ 2025-03-01 14:08 ` Zorro Lang
2025-03-02 13:13 ` Filipe Manana
2025-03-01 16:50 ` Zorro Lang
2 siblings, 1 reply; 23+ messages in thread
From: Zorro Lang @ 2025-03-01 14:08 UTC (permalink / raw)
To: David Sterba, Theodore Ts'o, Darrick J. Wong; +Cc: Zorro Lang, fstests
On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
> >
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
>
> I'm using a setup with a minimal VM system without systemd and such and
> dedicate the whole machine to one instance. I'm not interested in the
> check-parallel updates and test case separation. All fine if it is
> supported and lets me continue using single instance.
>
> But as I read it and the deprecation it's not going to be the supported
> use case. After last week update of fstests 100% of cases failed in the
> test setup (_seq_run). My workaround is to simply disable it by
>
> check:
> HAVE_PRIVATENS=
> HAVE_SYSTEMD_SCOPES=
>
> so I don't have to debug changes to the detection of the scope and
> namespaces and after each for-next update. I understand that with a
> custom system setup I'm on my own but until recently things have been
> fine but now after each update either test cases fail or the whole test
> infrastructure does not work.
>
> It's not just me who observes that. It seems that BTRFS is not tested
> before release as thoroughly as other filesystems (probably just XFS).
I test btrfs (only default), ext4 (+-fsverity, +-dax), ext3, exfat, xfs(1k, 4k,
64k blocksize, +-dax), tmpfs, nfs(base on xfs), cifs(on xfs), exfat, overlay
(on xfs) on aarch64, x86_64, s390x and ppc64le. But I'm not an expert of all
filesystems, so I just can check there's not big issue from my side for most of
fs. But different persons have different test ways, I can't try all different
test configs/ways on all filesystems by myself, I already take each weekend
to do these things, even I'm fever or on holiday. Even though I'm still asked
to release more fast...
Darrick's patchset has been in the list more than one month (since 2025-01-16)
to get reviewing. And I've tested Darrick's patchset several weeks, and talked
with Darrick several times about some issues I found. Darrick has done his best
to do that, please don't give him more pressure. But still sorry about I didn't
find the "100% fail" big issue in my test env. Feel free to share the config
you use, I'll refer to it to change my test.
I've gotten lots of pressure recently, I thought this release would be the end,
but looks like it's not. If you all (xfs, btrfs, ext4 and others) agree, I can
think about reverting the whole check-parallel and its related things, or there's
a switch to isolate the effect of check-parallel things. I thought there'll be a
painful period, but won't be too much if you don't use check-parallel directly.
I thought we will fix some bugs, then return to stable status. But I never thought
it's such painful. That's my fault...
Thanks,
Zorro
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-28 12:33 ` David Sterba
2025-02-28 17:33 ` Darrick J. Wong
2025-03-01 14:08 ` Zorro Lang
@ 2025-03-01 16:50 ` Zorro Lang
2025-03-04 18:58 ` Darrick J. Wong
2 siblings, 1 reply; 23+ messages in thread
From: Zorro Lang @ 2025-03-01 16:50 UTC (permalink / raw)
To: David Sterba; +Cc: Zorro Lang, fstests
On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
> >
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
>
> I'm using a setup with a minimal VM system without systemd and such and
> dedicate the whole machine to one instance. I'm not interested in the
> check-parallel updates and test case separation. All fine if it is
> supported and lets me continue using single instance.
>
> But as I read it and the deprecation it's not going to be the supported
> use case. After last week update of fstests 100% of cases failed in the
> test setup (_seq_run). My workaround is to simply disable it by
>
> check:
> HAVE_PRIVATENS=
> HAVE_SYSTEMD_SCOPES=
BTW, HAVE_SYSTEMD_SCOPES has been there several years, so if it works for
you before, it's not the problem of HAVE_SYSTEMD_SCOPES, even if your VM
doesn't have systemd.
So if it works for you by setting HAVE_PRIVATENS=(null), then the problem
maybe from the `./tools/run_privatens "./$seq"` part, and also means the
`./tools/run_setsid "./$seq"` part is good to you. Sorry I didn't hit
this failure even with btrfs, so if you can provide some details, we'll
look into it.
Thanks,
Zorro
>
> so I don't have to debug changes to the detection of the scope and
> namespaces and after each for-next update. I understand that with a
> custom system setup I'm on my own but until recently things have been
> fine but now after each update either test cases fail or the whole test
> infrastructure does not work.
>
> It's not just me who observes that. It seems that BTRFS is not tested
> before release as thoroughly as other filesystems (probably just XFS).
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-02-27 13:32 ` [ANNOUNCE] fstests: for-next branch updated to v2025.02.23 Filipe Manana
2025-02-27 17:52 ` Darrick J. Wong
@ 2025-03-01 17:22 ` Zorro Lang
2025-03-04 18:37 ` Darrick J. Wong
1 sibling, 1 reply; 23+ messages in thread
From: Zorro Lang @ 2025-03-01 17:22 UTC (permalink / raw)
To: Filipe Manana, Darrick J. Wong; +Cc: Zorro Lang, fstests, linux-btrfs
On Thu, Feb 27, 2025 at 01:32:42PM +0000, Filipe Manana wrote:
> On Sun, Feb 23, 2025 at 12:27 PM Zorro Lang <zlang@kernel.org> wrote:
> >
> > Hi all,
> >
> > The for-next branch of the xfstests repository at:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > has just been updated and tagged as v2025.02.23 release.
> >
> > Release Notes:
> > 1) There's not new test cases in this release, this's a release for bug fixes
> > particularly.
> > 2) Reiserfs part is removed from fstests.
> > 3) ltp/growfiles is removed too, I think no one needs it.
> >
> > I can't list all updates at here, more details please refer to below.
> > Thanks for all these contributions!
> >
> > Thanks,
> > Zorro
> >
> > The new head of the for-next branch is commit:
> >
> > 5b56a2d88819 fstests: remove reiserfs support
> >
> > New commits:
> >
> > Christoph Hellwig (1):
> > [04d0cf3f8909] generic/370: don't exclude XFS
> >
> > Darrick J. Wong (35):
> > [cc379f50f3bd] generic/476: fix fsstress process management
> > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > [777732b27e62] common/dump: don't replace pids arbitrarily
> > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > [77548e6066fd] common/rc: create a wrapper for the su command
> > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > [c71349150d34] common/rc: hoist pkill to a helper function
> > [91d2880aa029] tools: add a Makefile
> > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > [247ab01fa227] check: run tests in a private pid/mount namespace
>
> By the way, this commits breaks several btrfs test cases in the
> read_repair group:
>
> $ ./check -g read_repair
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/140 1s ... [failed, exit status 1]- output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad)
> --- tests/btrfs/140.out 2024-06-04 12:18:50.080308741 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad
> 2025-02-27 13:27:56.050933812 +0000
> @@ -1,3 +1,5 @@
> QA output created by 140
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +repair failed, csums don't match
> +(see /home/fdmanana/git/hub/xfstests/results//btrfs/140.full for details)
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad' to see
> the entire diff)
> btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
> --- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
> 2025-02-27 13:27:57.233352695 +0000
> @@ -1,3 +1,5 @@
> QA output created by 141
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +repair failed, csums don't match
> +(see /home/fdmanana/git/hub/xfstests/results//btrfs/141.full for details)
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/141.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad' to see
> the entire diff)
Sorry I didn't hit this failure on my last release test:
...
btrfs/140 1s ... 1s
btrfs/141 1s ... 1s
...
But by running them more times, I reproduce it manually now. And I noticed
that it won't be failed if disable HAVE_PRIVATENS. So your and David's bugs
are all from the `./tools/run_privatens "./$seq"` part.
I think below failures are same. You can disable HAVE_PRIVATENS and test
again. If everything goes well, or still something wrong, please tell me.
Hi Darrick, I think we're a bit hurry to promote the PRIVATENS way. I don't
want to give you too much pressure to face the issue from "run_privatens".
So how about just don't let it to be the "first-choice" to run ./$seq for now,
as it's not stable :-D
(1) if [ -n "${HAVE_PRIVATENS}" ]; then
./tools/run_privatens "./$seq"
...
(2) elif [ -n "${HAVE_SYSTEMD_SCOPES}" ]; then
...
systemd-run --quiet --unit "${unit}" --scope \
./tools/run_setsid "./$seq" &
...
(3) else
./tools/run_setsid "./$seq" &
...
fi
We have (2) and (3) for years (although they're changed a bit, but still works
well). Let's keep old ways at first, give the new way (1) some time to test and
improve. When other filesystems think it's good to use (1), then turn to it at
that time. What do you think?
Thanks,
Zorro
> btrfs/142 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad)
> --- tests/btrfs/142.out 2020-06-10 19:29:03.818519162 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad
> 2025-02-27 13:27:59.133249259 +0000
> @@ -1,37 +1,37 @@
> QA output created by 142
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/142.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad' to see
> the entire diff)
> btrfs/143 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad)
> --- tests/btrfs/143.out 2020-06-10 19:29:03.818519162 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad
> 2025-02-27 13:28:00.989680223 +0000
> @@ -1,37 +1,37 @@
> QA output created by 143
> wrote 131072/131072 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/143.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad' to see
> the entire diff)
> btrfs/150 1s ... 1s
> btrfs/157 2s ... 1s
> btrfs/215 1s ... 1s
> btrfs/265 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:28:05.589305927 +0000
> @@ -5,71 +5,71 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> btrfs/266 3s ... 2s
> btrfs/267 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad)
> --- tests/btrfs/267.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad
> 2025-02-27 13:28:09.161394788 +0000
> @@ -73,37 +73,37 @@
> XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> read 512/512 bytes
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/267.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad' to see
> the entire diff)
> btrfs/268 3s ... 2s
> btrfs/269 2s ... 1s
> btrfs/270 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad)
> --- tests/btrfs/270.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad
> 2025-02-27 13:28:14.090153054 +0000
> @@ -5,3 +5,4099 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> + 1 170 x 273 M-;
> + 2 136 ^ 273 M-;
> + 3 354 M-l 273 M-;
> + 4 320 M-P 273 M-;
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/270.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad' to see
> the entire diff)
> Ran: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/150 btrfs/157
> btrfs/215 btrfs/265 btrfs/266 btrfs/267 btrfs/268 btrfs/269 btrfs/270
> Failures: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/265 btrfs/267 btrfs/270
> Failed 7 of 13 tests
>
> The failures seems to be timing sensitive, as running a test
> individually doesn't always fails, for example:
>
> $ root 13:30:43 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 1s ... 2s
> Ran: btrfs/265
> Passed all 1 tests
>
> root 13:30:46 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 2s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:30:49.386584060 +0000
> @@ -5,71 +5,71 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> Ran: btrfs/265
> Failures: btrfs/265
> Failed 1 of 1 tests
>
> root 13:30:49 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 2s ... 1s
> Ran: btrfs/265
> Passed all 1 tests
>
> root 13:31:02 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/265 1s ... - output mismatch (see
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> 2025-02-27 13:31:05.522911416 +0000
> @@ -5,38 +5,38 @@
> step 2......corrupt file extent
> step 3......repair the bad copy
> step 4......check if the repair worked
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> ................
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> the entire diff)
> Ran: btrfs/265
> Failures: btrfs/265
> Failed 1 of 1 tests
>
> root 13:31:05 /home/fdmanana/git/hub/xfstests >
>
> Bisection using 100 iterations reliably points to that commit.
>
> Any ideas Darrick?
>
> Thanks.
>
>
>
> > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> > [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> > [5dc27fd20f80] mkfs: don't hardcode log size
> > [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> > [9505d04b8073] preamble: fix missing _kill_fsstress
> > [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> > [1bb15a27573e] generic/032: fix pinned mount failure
> > [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> > [040e74c89192] fuzzy: don't use readarray for xfsfind output
> > [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> > [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> > [96d29207c126] fix _require_scratch_duperemove ordering
> > [a8268531ca8b] fsstress: fix a memory leak
> > [e8e29e028faa] fsx: fix leaked log file pointer
> > [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> > [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> > [1c67e8b191fe] config: add FSX_PROG variable
> > [a553e7eba1cf] build: initialize stack variables to zero by default
> >
> > David Sterba (2):
> > [9049250b4042] fstests: remove ltp/growfiles
> > [5b56a2d88819] fstests: remove reiserfs support
> >
> > Filipe Manana (2):
> > [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> > [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
> >
> > Jeff Layton (1):
> > [bd6e01c81e21] generic/126: run it inside its own subdirectory
> >
> >
> > Code Diffstat:
> >
> > .gitignore | 1 -
> > Makefile | 2 +-
> > check | 91 +-
> > common/config | 12 +-
> > common/dump | 1 -
> > common/fuzzy | 104 +-
> > common/metadump | 42 +-
> > common/populate | 13 +-
> > common/preamble | 2 +-
> > common/quota | 6 +-
> > common/rc | 146 ++-
> > common/reflink | 2 +-
> > configure.ac | 1 +
> > include/builddefs.in | 3 +-
> > lib/tlibio.c | 2 +-
> > ltp/Makefile | 2 +-
> > ltp/fsstress.c | 1 +
> > ltp/fsx.c | 8 +-
> > ltp/growfiles.c | 2607 -------------------------------------------------
> > m4/package_libcdev.m4 | 14 +
> > src/nsexec.c | 18 +-
> > src/xfsfind.c | 14 +-
> > tests/btrfs/254 | 8 +-
> > tests/generic/019 | 2 +-
> > tests/generic/032 | 9 +
> > tests/generic/050 | 2 +-
> > tests/generic/075 | 2 +-
> > tests/generic/085 | 2 +-
> > tests/generic/093 | 2 +-
> > tests/generic/112 | 2 +-
> > tests/generic/125 | 2 +-
> > tests/generic/126 | 17 +-
> > tests/generic/127 | 16 +-
> > tests/generic/128 | 2 +-
> > tests/generic/193 | 36 +-
> > tests/generic/230 | 14 +-
> > tests/generic/231 | 4 +-
> > tests/generic/233 | 2 +-
> > tests/generic/270 | 12 +-
> > tests/generic/310 | 6 +-
> > tests/generic/314 | 2 +-
> > tests/generic/327 | 2 +-
> > tests/generic/328 | 4 +-
> > tests/generic/355 | 2 +-
> > tests/generic/361 | 4 +-
> > tests/generic/370 | 10 +-
> > tests/generic/453 | 6 +-
> > tests/generic/455 | 2 +-
> > tests/generic/456 | 2 +-
> > tests/generic/457 | 2 +-
> > tests/generic/469 | 2 +-
> > tests/generic/476 | 4 +-
> > tests/generic/499 | 2 +-
> > tests/generic/504 | 15 +-
> > tests/generic/511 | 2 +-
> > tests/generic/514 | 2 +-
> > tests/generic/530 | 6 +-
> > tests/generic/531 | 6 +-
> > tests/generic/561 | 2 +-
> > tests/generic/573 | 2 +-
> > tests/generic/590 | 2 +-
> > tests/generic/600 | 2 +-
> > tests/generic/601 | 2 +-
> > tests/generic/603 | 10 +-
> > tests/generic/642 | 2 +-
> > tests/generic/650 | 6 +-
> > tests/generic/673 | 2 +-
> > tests/generic/674 | 2 +-
> > tests/generic/675 | 2 +-
> > tests/generic/680 | 2 +-
> > tests/generic/681 | 2 +-
> > tests/generic/682 | 2 +-
> > tests/generic/683 | 2 +-
> > tests/generic/684 | 2 +-
> > tests/generic/685 | 2 +-
> > tests/generic/686 | 2 +-
> > tests/generic/687 | 2 +-
> > tests/generic/688 | 2 +-
> > tests/generic/691 | 8 +-
> > tests/generic/721 | 10 +-
> > tests/generic/726 | 2 +-
> > tests/generic/727 | 2 +-
> > tests/generic/740 | 2 +-
> > tests/generic/746 | 2 +-
> > tests/generic/750 | 2 +-
> > tests/generic/759 | 7 +-
> > tests/generic/760 | 7 +-
> > tests/xfs/149 | 2 +-
> > tests/xfs/501 | 2 +-
> > tests/xfs/502 | 2 +-
> > tests/xfs/530 | 2 +-
> > tests/xfs/720 | 2 +-
> > tests/xfs/795 | 2 +-
> > tests/xfs/803 | 2 +-
> > tools/Makefile | 21 +
> > tools/run_privatens | 28 +
> > tools/run_setsid | 22 +
> > 97 files changed, 596 insertions(+), 2890 deletions(-)
> > --
> > Zorro Lang
> > zlang@kernel.org
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-01 14:08 ` Zorro Lang
@ 2025-03-02 13:13 ` Filipe Manana
2025-03-02 14:50 ` Theodore Ts'o
2025-03-02 15:37 ` Zorro Lang
0 siblings, 2 replies; 23+ messages in thread
From: Filipe Manana @ 2025-03-02 13:13 UTC (permalink / raw)
To: Zorro Lang
Cc: David Sterba, Theodore Ts'o, Darrick J. Wong, Zorro Lang,
fstests
On Sat, Mar 1, 2025 at 2:09 PM Zorro Lang <zlang@redhat.com> wrote:
>
> On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > Hi all,
> > >
> > > The for-next branch of the xfstests repository at:
> > >
> > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > >
> > > has just been updated and tagged as v2025.02.23 release.
> > >
> > > Release Notes:
> > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > particularly.
> > > 2) Reiserfs part is removed from fstests.
> > > 3) ltp/growfiles is removed too, I think no one needs it.
> > >
> > > I can't list all updates at here, more details please refer to below.
> > > Thanks for all these contributions!
> > >
> > > Thanks,
> > > Zorro
> > >
> > > The new head of the for-next branch is commit:
> > >
> > > 5b56a2d88819 fstests: remove reiserfs support
> > >
> > > New commits:
> > >
> > > Christoph Hellwig (1):
> > > [04d0cf3f8909] generic/370: don't exclude XFS
> > >
> > > Darrick J. Wong (35):
> > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > [91d2880aa029] tools: add a Makefile
> > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > [247ab01fa227] check: run tests in a private pid/mount namespace
> > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> >
> > I'm using a setup with a minimal VM system without systemd and such and
> > dedicate the whole machine to one instance. I'm not interested in the
> > check-parallel updates and test case separation. All fine if it is
> > supported and lets me continue using single instance.
> >
> > But as I read it and the deprecation it's not going to be the supported
> > use case. After last week update of fstests 100% of cases failed in the
> > test setup (_seq_run). My workaround is to simply disable it by
> >
> > check:
> > HAVE_PRIVATENS=
> > HAVE_SYSTEMD_SCOPES=
> >
> > so I don't have to debug changes to the detection of the scope and
> > namespaces and after each for-next update. I understand that with a
> > custom system setup I'm on my own but until recently things have been
> > fine but now after each update either test cases fail or the whole test
> > infrastructure does not work.
> >
> > It's not just me who observes that. It seems that BTRFS is not tested
> > before release as thoroughly as other filesystems (probably just XFS).
>
> I test btrfs (only default), ext4 (+-fsverity, +-dax), ext3, exfat, xfs(1k, 4k,
> 64k blocksize, +-dax), tmpfs, nfs(base on xfs), cifs(on xfs), exfat, overlay
> (on xfs) on aarch64, x86_64, s390x and ppc64le. But I'm not an expert of all
> filesystems, so I just can check there's not big issue from my side for most of
> fs. But different persons have different test ways, I can't try all different
> test configs/ways on all filesystems by myself, I already take each weekend
> to do these things, even I'm fever or on holiday. Even though I'm still asked
> to release more fast...
>
> Darrick's patchset has been in the list more than one month (since 2025-01-16)
> to get reviewing. And I've tested Darrick's patchset several weeks, and talked
> with Darrick several times about some issues I found. Darrick has done his best
> to do that, please don't give him more pressure. But still sorry about I didn't
> find the "100% fail" big issue in my test env. Feel free to share the config
> you use, I'll refer to it to change my test.
A lot of the regressions that broke btrfs tests, or generic tests when
testing btrfs or ext4 for example, were not dependent on any specific
config.
I.e. no required MOUNT_OPTIONS or MKFS_OPTIONS, and failed with any
kind of devices used as scratch and test devices.
For example:
https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=a1d583fa0062f097b54dfb2b9b7ff1d9260c855c
This generic test started to fail on any fs other than xfs.
For me it failed with btrfs and ext4 (all the time).
Another example for another generic test case:
https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=7c5604ec86b82d118a3b84d7e5286740e652720d
Or this one:
https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=9b12a1a8a35bb491076332e21a113c43851ceb69
The dmdust device names changed but the btrfs tests were not updated,
so the tests always failed no matter what your setup config is.
So anyone running btrfs or ext4 with default settings (no mount or
mkfs options) should have run into the same failures.
I can't see how they wouldn't run into those failures in fact.
Or another example, a fix from Ted, for a generic test case that
always failed on ext4:
https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
And there are plenty of other examples.
More recently, from last week's update:
https://lore.kernel.org/fstests/b470cdee538aab91177f8295fb8886ae79f680db.1740662683.git.fdmanana@suse.com/
While it's too time consuming to test all major filesystems for all
possible configs, at least some basic testing can be done.
By basic testing I mean run the quick group without any mount and mkfs
options, which is reasonably fast and helps to catch a lot of
problems.
Thanks.
>
> I've gotten lots of pressure recently, I thought this release would be the end,
> but looks like it's not. If you all (xfs, btrfs, ext4 and others) agree, I can
> think about reverting the whole check-parallel and its related things, or there's
> a switch to isolate the effect of check-parallel things. I thought there'll be a
> painful period, but won't be too much if you don't use check-parallel directly.
> I thought we will fix some bugs, then return to stable status. But I never thought
> it's such painful. That's my fault...
>
> Thanks,
> Zorro
>
> >
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 13:13 ` Filipe Manana
@ 2025-03-02 14:50 ` Theodore Ts'o
2025-03-02 16:18 ` Zorro Lang
2025-03-02 18:42 ` Filipe Manana
2025-03-02 15:37 ` Zorro Lang
1 sibling, 2 replies; 23+ messages in thread
From: Theodore Ts'o @ 2025-03-02 14:50 UTC (permalink / raw)
To: Filipe Manana
Cc: Zorro Lang, David Sterba, Darrick J. Wong, Zorro Lang, fstests
On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> Or another example, a fix from Ted, for a generic test case that
> always failed on ext4:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
>
Actually, this fixed a bug which affected file systems for all file
systems *except* xfs, since the generic bug was injecting an
XFS-specific mkfs option into _scratch_mkfs. This was a *really*
obvious bug, but the problem was that commit 000813899afb ("fstests:
scale some tests for high CPU count sanity") made *huge* number of
changes, which made it hard to review the change, and also made it
harder for Dave to rebase the change, which is why, apparently,
pressure was applied to merge commit 000813899afb right before Dave
diappeared on vacation for a month. This is why I nated that there
appeared to be a double standarrd in place; I can't help but suspect
that if anyone *else* had sent in this commit, it would have been
rejected.
As far as testing, my understanding is that the huge amount of testing
happens between the promotion from for-next to the master branch.
This is why I used to make a point of upgrading my test appliance to
for-next, so I could help point out problems before most other
deveopers would see it in the master branch.
The fixes that you pointed out was all reasons why the master branch
hadn't been updated in months; it was because for-next still had
breakages. There is the challenge that when master hasn't gotten
updated for 2 or 3 months, it becomes harder to tell whether a test
failure was caused by a test bug, or a kernel bug. (It's not
impossible; for a while I was going to older versions of for-next, and
the comparing the results to newer versions of for-next, and then
filtering out new tests, but it's a bit of a pain.)
Ultimately, like most engineering tradeoffs this was a pain allocation
exercise. Dave didn't want to deal with rebasing changes, so the
check-parallel changes got merged to for-next early. This inflicted
pain on other xfstests developers.
- Ted
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 13:13 ` Filipe Manana
2025-03-02 14:50 ` Theodore Ts'o
@ 2025-03-02 15:37 ` Zorro Lang
2025-03-02 19:02 ` Filipe Manana
1 sibling, 1 reply; 23+ messages in thread
From: Zorro Lang @ 2025-03-02 15:37 UTC (permalink / raw)
To: Filipe Manana
Cc: Zorro Lang, David Sterba, Theodore Ts'o, Darrick J. Wong,
fstests
On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> On Sat, Mar 1, 2025 at 2:09 PM Zorro Lang <zlang@redhat.com> wrote:
> >
> > On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> > > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > > Hi all,
> > > >
> > > > The for-next branch of the xfstests repository at:
> > > >
> > > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > > >
> > > > has just been updated and tagged as v2025.02.23 release.
> > > >
> > > > Release Notes:
> > > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > > particularly.
> > > > 2) Reiserfs part is removed from fstests.
> > > > 3) ltp/growfiles is removed too, I think no one needs it.
> > > >
> > > > I can't list all updates at here, more details please refer to below.
> > > > Thanks for all these contributions!
> > > >
> > > > Thanks,
> > > > Zorro
> > > >
> > > > The new head of the for-next branch is commit:
> > > >
> > > > 5b56a2d88819 fstests: remove reiserfs support
> > > >
> > > > New commits:
> > > >
> > > > Christoph Hellwig (1):
> > > > [04d0cf3f8909] generic/370: don't exclude XFS
> > > >
> > > > Darrick J. Wong (35):
> > > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > > [91d2880aa029] tools: add a Makefile
> > > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > > [247ab01fa227] check: run tests in a private pid/mount namespace
> > > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > >
> > > I'm using a setup with a minimal VM system without systemd and such and
> > > dedicate the whole machine to one instance. I'm not interested in the
> > > check-parallel updates and test case separation. All fine if it is
> > > supported and lets me continue using single instance.
> > >
> > > But as I read it and the deprecation it's not going to be the supported
> > > use case. After last week update of fstests 100% of cases failed in the
> > > test setup (_seq_run). My workaround is to simply disable it by
> > >
> > > check:
> > > HAVE_PRIVATENS=
> > > HAVE_SYSTEMD_SCOPES=
> > >
> > > so I don't have to debug changes to the detection of the scope and
> > > namespaces and after each for-next update. I understand that with a
> > > custom system setup I'm on my own but until recently things have been
> > > fine but now after each update either test cases fail or the whole test
> > > infrastructure does not work.
> > >
> > > It's not just me who observes that. It seems that BTRFS is not tested
> > > before release as thoroughly as other filesystems (probably just XFS).
> >
> > I test btrfs (only default), ext4 (+-fsverity, +-dax), ext3, exfat, xfs(1k, 4k,
> > 64k blocksize, +-dax), tmpfs, nfs(base on xfs), cifs(on xfs), exfat, overlay
> > (on xfs) on aarch64, x86_64, s390x and ppc64le. But I'm not an expert of all
> > filesystems, so I just can check there's not big issue from my side for most of
> > fs. But different persons have different test ways, I can't try all different
> > test configs/ways on all filesystems by myself, I already take each weekend
> > to do these things, even I'm fever or on holiday. Even though I'm still asked
> > to release more fast...
> >
> > Darrick's patchset has been in the list more than one month (since 2025-01-16)
> > to get reviewing. And I've tested Darrick's patchset several weeks, and talked
> > with Darrick several times about some issues I found. Darrick has done his best
> > to do that, please don't give him more pressure. But still sorry about I didn't
> > find the "100% fail" big issue in my test env. Feel free to share the config
> > you use, I'll refer to it to change my test.
>
> A lot of the regressions that broke btrfs tests, or generic tests when
> testing btrfs or ext4 for example, were not dependent on any specific
> config.
> I.e. no required MOUNT_OPTIONS or MKFS_OPTIONS, and failed with any
> kind of devices used as scratch and test devices.
>
> For example:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=a1d583fa0062f097b54dfb2b9b7ff1d9260c855c
>
> This generic test started to fail on any fs other than xfs.
> For me it failed with btrfs and ext4 (all the time).
>
> Another example for another generic test case:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=7c5604ec86b82d118a3b84d7e5286740e652720d
>
> Or this one:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=9b12a1a8a35bb491076332e21a113c43851ceb69
>
> The dmdust device names changed but the btrfs tests were not updated,
> so the tests always failed no matter what your setup config is.
>
> So anyone running btrfs or ext4 with default settings (no mount or
> mkfs options) should have run into the same failures.
> I can't see how they wouldn't run into those failures in fact.
>
> Or another example, a fix from Ted, for a generic test case that
> always failed on ext4:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
>
> And there are plenty of other examples.
>
> More recently, from last week's update:
>
> https://lore.kernel.org/fstests/b470cdee538aab91177f8295fb8886ae79f680db.1740662683.git.fdmanana@suse.com/
>
> While it's too time consuming to test all major filesystems for all
> possible configs, at least some basic testing can be done.
> By basic testing I mean run the quick group without any mount and mkfs
> options, which is reasonably fast and helps to catch a lot of
> problems.
Sure :) I've added btrfs regression test to my regular test list recently. For now,
only default btrfs is tested by xfstests "auto" group. Sorry I'm not familar with
btrfs test currently, I hit several test failures, need time to figure out which
is test issue, which is progs' issue, which is kernel issue and which is known and
unknown issue and so on.
For example:
btrfs/007 fails as:
QA output created by 007
*** test send / receive
-*** done
+failed: '2097152000 200'
+(see /var/lib/xfstests/results//btrfs/007.full for details)
btrfs/060 blocks the whole test. Then btrfs/066 hang there after I
skip btrfs/060.
generic/363 fails as:
QA output created by 363
fsx -q -S 0 -e 1 -N 100000
+READ BAD DATA: offset = 0x1fb5d, size = 0xc502, fname = /mnt/test/junk
+OFFSET GOOD BAD RANGE
+0x2716c 0x0000 0x7f91 0x0
+operation# (mod 256) for the bad data may be 127
+0x2716d 0x0000 0x917f 0x1
...
(Run 'diff -u /root/git/xfstests/tests/generic/363.out /root/git/xfstests/results//default/generic/363.out.bad' to see the entire diff)
generic/427 fails as:
QA output created by 427
-Success, all done.
+pwrite: No space left on device
...
(Run 'diff -u /root/git/xfstests/tests/generic/427.out /root/git/xfstests/results//default/generic/427.out.bad' to see the entire diff)
generic/730 fails as:
QA output created by 730
-cat: -: Input/output error
...
(Run 'diff -u /root/git/xfstests/tests/generic/730.out /root/git/xfstests/results//default/generic/730.out.bad' to see the entire diff)
and some random failures on different test env. and so on ...
After I'm familar with known failures, I think things will get better. Please
feel free to share known issues (that you know) to me.
Besides btrfs, there're lots of filesystems, they all have different known/unknown
failures. It's not easy for someone to check most of filesystems' test failures
before release. I'll try to avoid critical issue, likes can't be built or installed,
whole or most of tests broken, system destroy, and so on. But for some test
failures, I might notice and remind in ANNOUNCE email, might not. Each release
might have bugs, likes RHEL, likes SUSE, Debian ... *each release might have
bugs, but we have to release, have to move on if there's not critical blocker
bugs.*
I'm sorry for the recent mess. I'll try my best to get xfstests back to track.
I think things is getting better, last release is the first fix release for that.
We'll have next fix release. Please be patient, if things is out of control, I'll
think about reverting the whole feature.
Thanks,
Zorro
>
>
> Thanks.
>
> >
> > I've gotten lots of pressure recently, I thought this release would be the end,
> > but looks like it's not. If you all (xfs, btrfs, ext4 and others) agree, I can
> > think about reverting the whole check-parallel and its related things, or there's
> > a switch to isolate the effect of check-parallel things. I thought there'll be a
> > painful period, but won't be too much if you don't use check-parallel directly.
> > I thought we will fix some bugs, then return to stable status. But I never thought
> > it's such painful. That's my fault...
> >
> > Thanks,
> > Zorro
> >
> > >
> >
> >
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 14:50 ` Theodore Ts'o
@ 2025-03-02 16:18 ` Zorro Lang
2025-03-02 18:42 ` Filipe Manana
1 sibling, 0 replies; 23+ messages in thread
From: Zorro Lang @ 2025-03-02 16:18 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Filipe Manana, Zorro Lang, David Sterba, Darrick J. Wong, fstests
On Sun, Mar 02, 2025 at 09:50:16AM -0500, Theodore Ts'o wrote:
> On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> > Or another example, a fix from Ted, for a generic test case that
> > always failed on ext4:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
> >
>
> Actually, this fixed a bug which affected file systems for all file
> systems *except* xfs, since the generic bug was injecting an
> XFS-specific mkfs option into _scratch_mkfs. This was a *really*
> obvious bug, but the problem was that commit 000813899afb ("fstests:
> scale some tests for high CPU count sanity") made *huge* number of
> changes, which made it hard to review the change, and also made it
> harder for Dave to rebase the change, which is why, apparently,
> pressure was applied to merge commit 000813899afb right before Dave
> diappeared on vacation for a month. This is why I nated that there
> appeared to be a double standarrd in place; I can't help but suspect
> that if anyone *else* had sent in this commit, it would have been
> rejected.
>
> As far as testing, my understanding is that the huge amount of testing
> happens between the promotion from for-next to the master branch.
> This is why I used to make a point of upgrading my test appliance to
> for-next, so I could help point out problems before most other
> deveopers would see it in the master branch.
Hi Ted,
Sorry, I was hurry to make a big step on xfstests... Although I just
brought in btrfs test into my regular test list recently (RHEL doesn't
support btrfs, I don't have the experience to test it). But ext4
is supported by us, I test ext4/3 with 1k/4k blocksize, fsverity, dax
before each xfstests release. Last ext4 regression test on v2025.02.23
was all passed on my side, except 4 known failures on g/044, g/045, g/046
and g/388:
XFSTESTS_END/[passed:542][notrun:259][known:4][unknown:0] PASS Score:0
Do I miss anything on extN testing, cause I didn't find most of test
failures on ext4? Please feel free to tell me what is better to be
tested on ext4 side before release xfstests, and what's optional. I'll
try to add it to my test list.
Thanks,
Zorro
>
> The fixes that you pointed out was all reasons why the master branch
> hadn't been updated in months; it was because for-next still had
> breakages. There is the challenge that when master hasn't gotten
> updated for 2 or 3 months, it becomes harder to tell whether a test
> failure was caused by a test bug, or a kernel bug. (It's not
> impossible; for a while I was going to older versions of for-next, and
> the comparing the results to newer versions of for-next, and then
> filtering out new tests, but it's a bit of a pain.)
>
> Ultimately, like most engineering tradeoffs this was a pain allocation
> exercise. Dave didn't want to deal with rebasing changes, so the
> check-parallel changes got merged to for-next early. This inflicted
> pain on other xfstests developers.
>
> - Ted
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 14:50 ` Theodore Ts'o
2025-03-02 16:18 ` Zorro Lang
@ 2025-03-02 18:42 ` Filipe Manana
1 sibling, 0 replies; 23+ messages in thread
From: Filipe Manana @ 2025-03-02 18:42 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Zorro Lang, David Sterba, Darrick J. Wong, Zorro Lang, fstests
On Sun, Mar 2, 2025 at 2:50 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> > Or another example, a fix from Ted, for a generic test case that
> > always failed on ext4:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
> >
>
> Actually, this fixed a bug which affected file systems for all file
> systems *except* xfs, since the generic bug was injecting an
> XFS-specific mkfs option into _scratch_mkfs.
No, it didn't affect btrfs, because -L exists for mkfs.btrfs and it's
used to set a label, which makes the test run fine.
> This was a *really*
> obvious bug, but the problem was that commit 000813899afb ("fstests:
> scale some tests for high CPU count sanity") made *huge* number of
> changes, which made it hard to review the change, and also made it
> harder for Dave to rebase the change, which is why, apparently,
> pressure was applied to merge commit 000813899afb right before Dave
> diappeared on vacation for a month. This is why I nated that there
> appeared to be a double standarrd in place; I can't help but suspect
> that if anyone *else* had sent in this commit, it would have been
> rejected.
>
> As far as testing, my understanding is that the huge amount of testing
> happens between the promotion from for-next to the master branch.
Probably so, because I have the feeling that most of the time there's
no testing for btrfs (and it seems ext4 too) when for-next is updated.
> This is why I used to make a point of upgrading my test appliance to
> for-next, so I could help point out problems before most other
> deveopers would see it in the master branch.
>
> The fixes that you pointed out was all reasons why the master branch
> hadn't been updated in months; it was because for-next still had
> breakages. There is the challenge that when master hasn't gotten
> updated for 2 or 3 months, it becomes harder to tell whether a test
> failure was caused by a test bug, or a kernel bug. (It's not
> impossible; for a while I was going to older versions of for-next, and
> the comparing the results to newer versions of for-next, and then
> filtering out new tests, but it's a bit of a pain.)
>
> Ultimately, like most engineering tradeoffs this was a pain allocation
> exercise. Dave didn't want to deal with rebasing changes, so the
> check-parallel changes got merged to for-next early. This inflicted
> pain on other xfstests developers.
>
> - Ted
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 15:37 ` Zorro Lang
@ 2025-03-02 19:02 ` Filipe Manana
2025-03-02 19:56 ` Zorro Lang
0 siblings, 1 reply; 23+ messages in thread
From: Filipe Manana @ 2025-03-02 19:02 UTC (permalink / raw)
To: Zorro Lang
Cc: Zorro Lang, David Sterba, Theodore Ts'o, Darrick J. Wong,
fstests
On Sun, Mar 2, 2025 at 3:37 PM Zorro Lang <zlang@kernel.org> wrote:
>
> On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> > On Sat, Mar 1, 2025 at 2:09 PM Zorro Lang <zlang@redhat.com> wrote:
> > >
> > > On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> > > > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > > > Hi all,
> > > > >
> > > > > The for-next branch of the xfstests repository at:
> > > > >
> > > > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > > > >
> > > > > has just been updated and tagged as v2025.02.23 release.
> > > > >
> > > > > Release Notes:
> > > > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > > > particularly.
> > > > > 2) Reiserfs part is removed from fstests.
> > > > > 3) ltp/growfiles is removed too, I think no one needs it.
> > > > >
> > > > > I can't list all updates at here, more details please refer to below.
> > > > > Thanks for all these contributions!
> > > > >
> > > > > Thanks,
> > > > > Zorro
> > > > >
> > > > > The new head of the for-next branch is commit:
> > > > >
> > > > > 5b56a2d88819 fstests: remove reiserfs support
> > > > >
> > > > > New commits:
> > > > >
> > > > > Christoph Hellwig (1):
> > > > > [04d0cf3f8909] generic/370: don't exclude XFS
> > > > >
> > > > > Darrick J. Wong (35):
> > > > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > > > [91d2880aa029] tools: add a Makefile
> > > > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > > > [247ab01fa227] check: run tests in a private pid/mount namespace
> > > > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > > >
> > > > I'm using a setup with a minimal VM system without systemd and such and
> > > > dedicate the whole machine to one instance. I'm not interested in the
> > > > check-parallel updates and test case separation. All fine if it is
> > > > supported and lets me continue using single instance.
> > > >
> > > > But as I read it and the deprecation it's not going to be the supported
> > > > use case. After last week update of fstests 100% of cases failed in the
> > > > test setup (_seq_run). My workaround is to simply disable it by
> > > >
> > > > check:
> > > > HAVE_PRIVATENS=
> > > > HAVE_SYSTEMD_SCOPES=
> > > >
> > > > so I don't have to debug changes to the detection of the scope and
> > > > namespaces and after each for-next update. I understand that with a
> > > > custom system setup I'm on my own but until recently things have been
> > > > fine but now after each update either test cases fail or the whole test
> > > > infrastructure does not work.
> > > >
> > > > It's not just me who observes that. It seems that BTRFS is not tested
> > > > before release as thoroughly as other filesystems (probably just XFS).
> > >
> > > I test btrfs (only default), ext4 (+-fsverity, +-dax), ext3, exfat, xfs(1k, 4k,
> > > 64k blocksize, +-dax), tmpfs, nfs(base on xfs), cifs(on xfs), exfat, overlay
> > > (on xfs) on aarch64, x86_64, s390x and ppc64le. But I'm not an expert of all
> > > filesystems, so I just can check there's not big issue from my side for most of
> > > fs. But different persons have different test ways, I can't try all different
> > > test configs/ways on all filesystems by myself, I already take each weekend
> > > to do these things, even I'm fever or on holiday. Even though I'm still asked
> > > to release more fast...
> > >
> > > Darrick's patchset has been in the list more than one month (since 2025-01-16)
> > > to get reviewing. And I've tested Darrick's patchset several weeks, and talked
> > > with Darrick several times about some issues I found. Darrick has done his best
> > > to do that, please don't give him more pressure. But still sorry about I didn't
> > > find the "100% fail" big issue in my test env. Feel free to share the config
> > > you use, I'll refer to it to change my test.
> >
> > A lot of the regressions that broke btrfs tests, or generic tests when
> > testing btrfs or ext4 for example, were not dependent on any specific
> > config.
> > I.e. no required MOUNT_OPTIONS or MKFS_OPTIONS, and failed with any
> > kind of devices used as scratch and test devices.
> >
> > For example:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=a1d583fa0062f097b54dfb2b9b7ff1d9260c855c
> >
> > This generic test started to fail on any fs other than xfs.
> > For me it failed with btrfs and ext4 (all the time).
> >
> > Another example for another generic test case:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=7c5604ec86b82d118a3b84d7e5286740e652720d
> >
> > Or this one:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=9b12a1a8a35bb491076332e21a113c43851ceb69
> >
> > The dmdust device names changed but the btrfs tests were not updated,
> > so the tests always failed no matter what your setup config is.
> >
> > So anyone running btrfs or ext4 with default settings (no mount or
> > mkfs options) should have run into the same failures.
> > I can't see how they wouldn't run into those failures in fact.
> >
> > Or another example, a fix from Ted, for a generic test case that
> > always failed on ext4:
> >
> > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
> >
> > And there are plenty of other examples.
> >
> > More recently, from last week's update:
> >
> > https://lore.kernel.org/fstests/b470cdee538aab91177f8295fb8886ae79f680db.1740662683.git.fdmanana@suse.com/
> >
> > While it's too time consuming to test all major filesystems for all
> > possible configs, at least some basic testing can be done.
> > By basic testing I mean run the quick group without any mount and mkfs
> > options, which is reasonably fast and helps to catch a lot of
> > problems.
>
> Sure :) I've added btrfs regression test to my regular test list recently.
Ok, so until very recently there was no testing at all?
> For now,
> only default btrfs is tested by xfstests "auto" group. Sorry I'm not familar with
> btrfs test currently, I hit several test failures, need time to figure out which
> is test issue, which is progs' issue, which is kernel issue and which is known and
> unknown issue and so on.
You don't need to be an expert on btrfs, not much less figure out
which kernels have fixes, btrfs-progs versions, for which configs,
etc.
That's even hard for us btrfs developers when dealing with stable
releases, distros, etc.
All that needs to be done, and this would have catched all the recent
bugs from the last 2+ months, is:
1) Create a branch based on for-next;
2) Apply all the patches you want from the mailing list;
3) Run the quick group for btrfs (or ext4, or whatever) without any
mount and mkfs options;
4) For any test that fails, verify if they fail too on for-next
without the new patches.
If they fail too, then it's unlikely to be a regression.
If they pass on for-next, bisect which new patch introduces the
regression and notify the author.
This would have caught all the recent regressions we had.
>
> For example:
> btrfs/007 fails as:
>
> QA output created by 007
> *** test send / receive
> -*** done
> +failed: '2097152000 200'
> +(see /var/lib/xfstests/results//btrfs/007.full for details)
This sounds like what was fixed in:
https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=1f32af6a4ce98f8185ca62c31e3bd014f0690898
>
> btrfs/060 blocks the whole test. Then btrfs/066 hang there after I
> skip btrfs/060.
They run fine for me, and afaik no one else is running into that.
When you get such failure, please report them, provide dmesg if there
are stack traces there.
>
> generic/363 fails as:
>
> QA output created by 363
> fsx -q -S 0 -e 1 -N 100000
> +READ BAD DATA: offset = 0x1fb5d, size = 0xc502, fname = /mnt/test/junk
> +OFFSET GOOD BAD RANGE
> +0x2716c 0x0000 0x7f91 0x0
> +operation# (mod 256) for the bad data may be 127
> +0x2716d 0x0000 0x917f 0x1
> ...
> (Run 'diff -u /root/git/xfstests/tests/generic/363.out /root/git/xfstests/results//default/generic/363.out.bad' to see the entire diff)
This was fixed recently in 6.14-rc3 :
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da2dccd7451de62b175fb8f0808d644959e964c7
>
> generic/427 fails as:
>
> QA output created by 427
> -Success, all done.
> +pwrite: No space left on device
> ...
> (Run 'diff -u /root/git/xfstests/tests/generic/427.out /root/git/xfstests/results//default/generic/427.out.bad' to see the entire diff)
Works for me, with a 10g and 100g scratch/test devices:
$ ./check generic/427
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
generic/427 4s ... 2s
Ran: generic/427
Passed all 1 tests
>
> generic/730 fails as:
>
> QA output created by 730
> -cat: -: Input/output error
> ...
> (Run 'diff -u /root/git/xfstests/tests/generic/730.out /root/git/xfstests/results//default/generic/730.out.bad' to see the entire diff)
This one is known to fail.
>
> and some random failures on different test env. and so on ...
>
> After I'm familar with known failures, I think things will get better. Please
> feel free to share known issues (that you know) to me.
>
> Besides btrfs, there're lots of filesystems, they all have different known/unknown
> failures. It's not easy for someone to check most of filesystems' test failures
> before release. I'll try to avoid critical issue, likes can't be built or installed,
> whole or most of tests broken, system destroy, and so on. But for some test
> failures, I might notice and remind in ANNOUNCE email, might not. Each release
> might have bugs, likes RHEL, likes SUSE, Debian ... *each release might have
> bugs, but we have to release, have to move on if there's not critical blocker
> bugs.*
Sure, and no one is on track with known bugs for every filesystem on
every upstream kernel, distro kernel, tool versions, etc.
As said before, even for us developers it's hard to keep track of things.
Just try the suggestion mentioned before - it's enough to catch most
regressions, and it would have caught all the recent regressions.
It's what I do when I make changes to generic tests and shared code -
it's not bulletproof for sure, but it catches many obvious bugs and is
infinitely better than not doing any testing at all.
Don't stress on not being an expert of all filesystems, because no one
is and no one expects you to be.
Thanks.
>
> I'm sorry for the recent mess. I'll try my best to get xfstests back to track.
> I think things is getting better, last release is the first fix release for that.
> We'll have next fix release. Please be patient, if things is out of control, I'll
> think about reverting the whole feature.
>
> Thanks,
> Zorro
>
> >
> >
> > Thanks.
> >
> > >
> > > I've gotten lots of pressure recently, I thought this release would be the end,
> > > but looks like it's not. If you all (xfs, btrfs, ext4 and others) agree, I can
> > > think about reverting the whole check-parallel and its related things, or there's
> > > a switch to isolate the effect of check-parallel things. I thought there'll be a
> > > painful period, but won't be too much if you don't use check-parallel directly.
> > > I thought we will fix some bugs, then return to stable status. But I never thought
> > > it's such painful. That's my fault...
> > >
> > > Thanks,
> > > Zorro
> > >
> > > >
> > >
> > >
> >
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-02 19:02 ` Filipe Manana
@ 2025-03-02 19:56 ` Zorro Lang
0 siblings, 0 replies; 23+ messages in thread
From: Zorro Lang @ 2025-03-02 19:56 UTC (permalink / raw)
To: Filipe Manana
Cc: Zorro Lang, David Sterba, Theodore Ts'o, Darrick J. Wong,
fstests
On Sun, Mar 02, 2025 at 07:02:15PM +0000, Filipe Manana wrote:
> On Sun, Mar 2, 2025 at 3:37 PM Zorro Lang <zlang@kernel.org> wrote:
> >
> > On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote:
> > > On Sat, Mar 1, 2025 at 2:09 PM Zorro Lang <zlang@redhat.com> wrote:
> > > >
> > > > On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> > > > > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > The for-next branch of the xfstests repository at:
> > > > > >
> > > > > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > > > > >
> > > > > > has just been updated and tagged as v2025.02.23 release.
> > > > > >
> > > > > > Release Notes:
> > > > > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > > > > particularly.
> > > > > > 2) Reiserfs part is removed from fstests.
> > > > > > 3) ltp/growfiles is removed too, I think no one needs it.
> > > > > >
> > > > > > I can't list all updates at here, more details please refer to below.
> > > > > > Thanks for all these contributions!
> > > > > >
> > > > > > Thanks,
> > > > > > Zorro
> > > > > >
> > > > > > The new head of the for-next branch is commit:
> > > > > >
> > > > > > 5b56a2d88819 fstests: remove reiserfs support
> > > > > >
> > > > > > New commits:
> > > > > >
> > > > > > Christoph Hellwig (1):
> > > > > > [04d0cf3f8909] generic/370: don't exclude XFS
> > > > > >
> > > > > > Darrick J. Wong (35):
> > > > > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > > > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > > > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > > > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > > > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > > > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > > > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > > > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > > > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > > > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > > > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > > > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > > > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > > > > [91d2880aa029] tools: add a Makefile
> > > > > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > > > > [247ab01fa227] check: run tests in a private pid/mount namespace
> > > > > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > > > >
> > > > > I'm using a setup with a minimal VM system without systemd and such and
> > > > > dedicate the whole machine to one instance. I'm not interested in the
> > > > > check-parallel updates and test case separation. All fine if it is
> > > > > supported and lets me continue using single instance.
> > > > >
> > > > > But as I read it and the deprecation it's not going to be the supported
> > > > > use case. After last week update of fstests 100% of cases failed in the
> > > > > test setup (_seq_run). My workaround is to simply disable it by
> > > > >
> > > > > check:
> > > > > HAVE_PRIVATENS=
> > > > > HAVE_SYSTEMD_SCOPES=
> > > > >
> > > > > so I don't have to debug changes to the detection of the scope and
> > > > > namespaces and after each for-next update. I understand that with a
> > > > > custom system setup I'm on my own but until recently things have been
> > > > > fine but now after each update either test cases fail or the whole test
> > > > > infrastructure does not work.
> > > > >
> > > > > It's not just me who observes that. It seems that BTRFS is not tested
> > > > > before release as thoroughly as other filesystems (probably just XFS).
> > > >
> > > > I test btrfs (only default), ext4 (+-fsverity, +-dax), ext3, exfat, xfs(1k, 4k,
> > > > 64k blocksize, +-dax), tmpfs, nfs(base on xfs), cifs(on xfs), exfat, overlay
> > > > (on xfs) on aarch64, x86_64, s390x and ppc64le. But I'm not an expert of all
> > > > filesystems, so I just can check there's not big issue from my side for most of
> > > > fs. But different persons have different test ways, I can't try all different
> > > > test configs/ways on all filesystems by myself, I already take each weekend
> > > > to do these things, even I'm fever or on holiday. Even though I'm still asked
> > > > to release more fast...
> > > >
> > > > Darrick's patchset has been in the list more than one month (since 2025-01-16)
> > > > to get reviewing. And I've tested Darrick's patchset several weeks, and talked
> > > > with Darrick several times about some issues I found. Darrick has done his best
> > > > to do that, please don't give him more pressure. But still sorry about I didn't
> > > > find the "100% fail" big issue in my test env. Feel free to share the config
> > > > you use, I'll refer to it to change my test.
> > >
> > > A lot of the regressions that broke btrfs tests, or generic tests when
> > > testing btrfs or ext4 for example, were not dependent on any specific
> > > config.
> > > I.e. no required MOUNT_OPTIONS or MKFS_OPTIONS, and failed with any
> > > kind of devices used as scratch and test devices.
> > >
> > > For example:
> > >
> > > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=a1d583fa0062f097b54dfb2b9b7ff1d9260c855c
> > >
> > > This generic test started to fail on any fs other than xfs.
> > > For me it failed with btrfs and ext4 (all the time).
> > >
> > > Another example for another generic test case:
> > >
> > > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=7c5604ec86b82d118a3b84d7e5286740e652720d
> > >
> > > Or this one:
> > >
> > > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=9b12a1a8a35bb491076332e21a113c43851ceb69
> > >
> > > The dmdust device names changed but the btrfs tests were not updated,
> > > so the tests always failed no matter what your setup config is.
> > >
> > > So anyone running btrfs or ext4 with default settings (no mount or
> > > mkfs options) should have run into the same failures.
> > > I can't see how they wouldn't run into those failures in fact.
> > >
> > > Or another example, a fix from Ted, for a generic test case that
> > > always failed on ext4:
> > >
> > > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e
> > >
> > > And there are plenty of other examples.
> > >
> > > More recently, from last week's update:
> > >
> > > https://lore.kernel.org/fstests/b470cdee538aab91177f8295fb8886ae79f680db.1740662683.git.fdmanana@suse.com/
> > >
> > > While it's too time consuming to test all major filesystems for all
> > > possible configs, at least some basic testing can be done.
> > > By basic testing I mean run the quick group without any mount and mkfs
> > > options, which is reasonably fast and helps to catch a lot of
> > > problems.
> >
> > Sure :) I've added btrfs regression test to my regular test list recently.
>
> Ok, so until very recently there was no testing at all?
No, I test with RHEL system, RHEL doesn't have btrfs support, it doesn't build btrfs
module and progs. So our test related things don't support btrfs test either.
And btrfs related patches are tested by Anand at first, so I paid more attention
to other fs test. Everything looks good, until recently, btrfs related bugs are
reported more, then I started to change our internal test scripts to support upstream
btrfs test.
>
> > For now,
> > only default btrfs is tested by xfstests "auto" group. Sorry I'm not familar with
> > btrfs test currently, I hit several test failures, need time to figure out which
> > is test issue, which is progs' issue, which is kernel issue and which is known and
> > unknown issue and so on.
>
> You don't need to be an expert on btrfs, not much less figure out
> which kernels have fixes, btrfs-progs versions, for which configs,
> etc.
> That's even hard for us btrfs developers when dealing with stable
> releases, distros, etc.
>
> All that needs to be done, and this would have catched all the recent
> bugs from the last 2+ months, is:
>
> 1) Create a branch based on for-next;
>
> 2) Apply all the patches you want from the mailing list;
>
> 3) Run the quick group for btrfs (or ext4, or whatever) without any
> mount and mkfs options;
>
> 4) For any test that fails, verify if they fail too on for-next
> without the new patches.
> If they fail too, then it's unlikely to be a regression.
> If they pass on for-next, bisect which new patch introduces the
> regression and notify the author.
>
> This would have caught all the recent regressions we had.
Yeah, I planned to do that later. But I have to say, some random failures are
hard to be compared. I don't test in similar VMs with similar hardware. We have
many different kinds of test machines with different hardwares. There might be
some failures be triggered randomly. I can't promise I'll find all real bugs,
just try my best to give btrfs a basic cover.
And if we have *big* changes on fstests infrastructure later, I'll notice btrfs
and ext4, to check if you'd like to give it a test (not only xfs), then I push
it after getting your feedback. Actually it's not I'm only care about xfs, I
only do half of xfs tests, for example I don't test xfs RT and don't run hundreds
of xfs cases not in auto group. Just Darrick really would like to help to test
from his side and feedback sometimes.
Thanks,
Zorro
>
> >
> > For example:
> > btrfs/007 fails as:
> >
> > QA output created by 007
> > *** test send / receive
> > -*** done
> > +failed: '2097152000 200'
> > +(see /var/lib/xfstests/results//btrfs/007.full for details)
>
> This sounds like what was fixed in:
>
> https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=1f32af6a4ce98f8185ca62c31e3bd014f0690898
>
> >
> > btrfs/060 blocks the whole test. Then btrfs/066 hang there after I
> > skip btrfs/060.
>
> They run fine for me, and afaik no one else is running into that.
> When you get such failure, please report them, provide dmesg if there
> are stack traces there.
>
> >
> > generic/363 fails as:
> >
> > QA output created by 363
> > fsx -q -S 0 -e 1 -N 100000
> > +READ BAD DATA: offset = 0x1fb5d, size = 0xc502, fname = /mnt/test/junk
> > +OFFSET GOOD BAD RANGE
> > +0x2716c 0x0000 0x7f91 0x0
> > +operation# (mod 256) for the bad data may be 127
> > +0x2716d 0x0000 0x917f 0x1
> > ...
> > (Run 'diff -u /root/git/xfstests/tests/generic/363.out /root/git/xfstests/results//default/generic/363.out.bad' to see the entire diff)
>
> This was fixed recently in 6.14-rc3 :
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da2dccd7451de62b175fb8f0808d644959e964c7
>
> >
> > generic/427 fails as:
> >
> > QA output created by 427
> > -Success, all done.
> > +pwrite: No space left on device
> > ...
> > (Run 'diff -u /root/git/xfstests/tests/generic/427.out /root/git/xfstests/results//default/generic/427.out.bad' to see the entire diff)
>
> Works for me, with a 10g and 100g scratch/test devices:
>
> $ ./check generic/427
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> generic/427 4s ... 2s
> Ran: generic/427
> Passed all 1 tests
>
> >
> > generic/730 fails as:
> >
> > QA output created by 730
> > -cat: -: Input/output error
> > ...
> > (Run 'diff -u /root/git/xfstests/tests/generic/730.out /root/git/xfstests/results//default/generic/730.out.bad' to see the entire diff)
>
> This one is known to fail.
>
> >
> > and some random failures on different test env. and so on ...
> >
> > After I'm familar with known failures, I think things will get better. Please
> > feel free to share known issues (that you know) to me.
> >
> > Besides btrfs, there're lots of filesystems, they all have different known/unknown
> > failures. It's not easy for someone to check most of filesystems' test failures
> > before release. I'll try to avoid critical issue, likes can't be built or installed,
> > whole or most of tests broken, system destroy, and so on. But for some test
> > failures, I might notice and remind in ANNOUNCE email, might not. Each release
> > might have bugs, likes RHEL, likes SUSE, Debian ... *each release might have
> > bugs, but we have to release, have to move on if there's not critical blocker
> > bugs.*
>
> Sure, and no one is on track with known bugs for every filesystem on
> every upstream kernel, distro kernel, tool versions, etc.
> As said before, even for us developers it's hard to keep track of things.
>
> Just try the suggestion mentioned before - it's enough to catch most
> regressions, and it would have caught all the recent regressions.
> It's what I do when I make changes to generic tests and shared code -
> it's not bulletproof for sure, but it catches many obvious bugs and is
> infinitely better than not doing any testing at all.
>
> Don't stress on not being an expert of all filesystems, because no one
> is and no one expects you to be.
>
> Thanks.
>
> >
> > I'm sorry for the recent mess. I'll try my best to get xfstests back to track.
> > I think things is getting better, last release is the first fix release for that.
> > We'll have next fix release. Please be patient, if things is out of control, I'll
> > think about reverting the whole feature.
> >
> > Thanks,
> > Zorro
> >
> > >
> > >
> > > Thanks.
> > >
> > > >
> > > > I've gotten lots of pressure recently, I thought this release would be the end,
> > > > but looks like it's not. If you all (xfs, btrfs, ext4 and others) agree, I can
> > > > think about reverting the whole check-parallel and its related things, or there's
> > > > a switch to isolate the effect of check-parallel things. I thought there'll be a
> > > > painful period, but won't be too much if you don't use check-parallel directly.
> > > > I thought we will fix some bugs, then return to stable status. But I never thought
> > > > it's such painful. That's my fault...
> > > >
> > > > Thanks,
> > > > Zorro
> > > >
> > > > >
> > > >
> > > >
> > >
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-01 17:22 ` Zorro Lang
@ 2025-03-04 18:37 ` Darrick J. Wong
0 siblings, 0 replies; 23+ messages in thread
From: Darrick J. Wong @ 2025-03-04 18:37 UTC (permalink / raw)
To: Zorro Lang; +Cc: Filipe Manana, Zorro Lang, fstests, linux-btrfs
On Sun, Mar 02, 2025 at 01:22:50AM +0800, Zorro Lang wrote:
> On Thu, Feb 27, 2025 at 01:32:42PM +0000, Filipe Manana wrote:
> > On Sun, Feb 23, 2025 at 12:27 PM Zorro Lang <zlang@kernel.org> wrote:
> > >
> > > Hi all,
> > >
> > > The for-next branch of the xfstests repository at:
> > >
> > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > >
> > > has just been updated and tagged as v2025.02.23 release.
> > >
> > > Release Notes:
> > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > particularly.
> > > 2) Reiserfs part is removed from fstests.
> > > 3) ltp/growfiles is removed too, I think no one needs it.
> > >
> > > I can't list all updates at here, more details please refer to below.
> > > Thanks for all these contributions!
> > >
> > > Thanks,
> > > Zorro
> > >
> > > The new head of the for-next branch is commit:
> > >
> > > 5b56a2d88819 fstests: remove reiserfs support
> > >
> > > New commits:
> > >
> > > Christoph Hellwig (1):
> > > [04d0cf3f8909] generic/370: don't exclude XFS
> > >
> > > Darrick J. Wong (35):
> > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > [91d2880aa029] tools: add a Makefile
> > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > [247ab01fa227] check: run tests in a private pid/mount namespace
> >
> > By the way, this commits breaks several btrfs test cases in the
> > read_repair group:
> >
> > $ ./check -g read_repair
> > FSTYP -- btrfs
> > PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> > SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> > MKFS_OPTIONS -- /dev/sdc
> > MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
> >
> > btrfs/140 1s ... [failed, exit status 1]- output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad)
> > --- tests/btrfs/140.out 2024-06-04 12:18:50.080308741 +0100
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad
> > 2025-02-27 13:27:56.050933812 +0000
> > @@ -1,3 +1,5 @@
> > QA output created by 140
> > wrote 131072/131072 bytes
> > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > +repair failed, csums don't match
> > +(see /home/fdmanana/git/hub/xfstests/results//btrfs/140.full for details)
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad' to see
> > the entire diff)
> > btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
> > --- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
> > 2025-02-27 13:27:57.233352695 +0000
> > @@ -1,3 +1,5 @@
> > QA output created by 141
> > wrote 131072/131072 bytes
> > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > +repair failed, csums don't match
> > +(see /home/fdmanana/git/hub/xfstests/results//btrfs/141.full for details)
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/141.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad' to see
> > the entire diff)
>
> Sorry I didn't hit this failure on my last release test:
> ...
> btrfs/140 1s ... 1s
> btrfs/141 1s ... 1s
> ...
>
> But by running them more times, I reproduce it manually now. And I noticed
> that it won't be failed if disable HAVE_PRIVATENS. So your and David's bugs
> are all from the `./tools/run_privatens "./$seq"` part.
>
> I think below failures are same. You can disable HAVE_PRIVATENS and test
> again. If everything goes well, or still something wrong, please tell me.
>
> Hi Darrick, I think we're a bit hurry to promote the PRIVATENS way. I don't
> want to give you too much pressure to face the issue from "run_privatens".
> So how about just don't let it to be the "first-choice" to run ./$seq for now,
> as it's not stable :-D
>
> (1) if [ -n "${HAVE_PRIVATENS}" ]; then
> ./tools/run_privatens "./$seq"
> ...
> (2) elif [ -n "${HAVE_SYSTEMD_SCOPES}" ]; then
> ...
> systemd-run --quiet --unit "${unit}" --scope \
> ./tools/run_setsid "./$seq" &
> ...
> (3) else
> ./tools/run_setsid "./$seq" &
> ...
> fi
>
> We have (2) and (3) for years (although they're changed a bit, but still works
> well). Let's keep old ways at first, give the new way (1) some time to test and
> improve. When other filesystems think it's good to use (1), then turn to it at
> that time. What do you think?
(Reiterating something we're discussing in irc now)
What if btrfs/140 (and everything else using the _btrfs*read_on_mirror
functions) called a "_require_non_privatens" function:
_require_non_privatens() {
test "$FSTESTS_ISOL" == "privatens" && \
_notrun "test requires global pid/mount namespace"
}
And then ./check can detect such tests via
"grep -q _require_non_privatens ./$seq" and pick run_setsid instead?
Note: I don't actually know how to detect that ./check itself is being
run in a private pid/mount namespace, but I think these tests are broken
there anyway.
--D
> Thanks,
> Zorro
>
> > btrfs/142 1s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad)
> > --- tests/btrfs/142.out 2020-06-10 19:29:03.818519162 +0100
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad
> > 2025-02-27 13:27:59.133249259 +0000
> > @@ -1,37 +1,37 @@
> > QA output created by 142
> > wrote 131072/131072 bytes
> > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/142.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/142.out.bad' to see
> > the entire diff)
> > btrfs/143 1s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad)
> > --- tests/btrfs/143.out 2020-06-10 19:29:03.818519162 +0100
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad
> > 2025-02-27 13:28:00.989680223 +0000
> > @@ -1,37 +1,37 @@
> > QA output created by 143
> > wrote 131072/131072 bytes
> > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/143.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/143.out.bad' to see
> > the entire diff)
> > btrfs/150 1s ... 1s
> > btrfs/157 2s ... 1s
> > btrfs/215 1s ... 1s
> > btrfs/265 2s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> > --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> > 2025-02-27 13:28:05.589305927 +0000
> > @@ -5,71 +5,71 @@
> > step 2......corrupt file extent
> > step 3......repair the bad copy
> > step 4......check if the repair worked
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> > the entire diff)
> > btrfs/266 3s ... 2s
> > btrfs/267 2s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad)
> > --- tests/btrfs/267.out 2023-03-02 21:47:53.876609426 +0000
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad
> > 2025-02-27 13:28:09.161394788 +0000
> > @@ -73,37 +73,37 @@
> > XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > read 512/512 bytes
> > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/267.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/267.out.bad' to see
> > the entire diff)
> > btrfs/268 3s ... 2s
> > btrfs/269 2s ... 1s
> > btrfs/270 1s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad)
> > --- tests/btrfs/270.out 2023-03-02 21:47:53.876609426 +0000
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad
> > 2025-02-27 13:28:14.090153054 +0000
> > @@ -5,3 +5,4099 @@
> > step 2......corrupt file extent
> > step 3......repair the bad copy
> > step 4......check if the repair worked
> > + 1 170 x 273 M-;
> > + 2 136 ^ 273 M-;
> > + 3 354 M-l 273 M-;
> > + 4 320 M-P 273 M-;
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/270.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/270.out.bad' to see
> > the entire diff)
> > Ran: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/150 btrfs/157
> > btrfs/215 btrfs/265 btrfs/266 btrfs/267 btrfs/268 btrfs/269 btrfs/270
> > Failures: btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/265 btrfs/267 btrfs/270
> > Failed 7 of 13 tests
> >
> > The failures seems to be timing sensitive, as running a test
> > individually doesn't always fails, for example:
> >
> > $ root 13:30:43 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> > FSTYP -- btrfs
> > PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> > SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> > MKFS_OPTIONS -- /dev/sdc
> > MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
> >
> > btrfs/265 1s ... 2s
> > Ran: btrfs/265
> > Passed all 1 tests
> >
> > root 13:30:46 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> > FSTYP -- btrfs
> > PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> > SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> > MKFS_OPTIONS -- /dev/sdc
> > MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
> >
> > btrfs/265 2s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> > --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> > 2025-02-27 13:30:49.386584060 +0000
> > @@ -5,71 +5,71 @@
> > step 2......corrupt file extent
> > step 3......repair the bad copy
> > step 4......check if the repair worked
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> > the entire diff)
> > Ran: btrfs/265
> > Failures: btrfs/265
> > Failed 1 of 1 tests
> >
> > root 13:30:49 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> > FSTYP -- btrfs
> > PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> > SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> > MKFS_OPTIONS -- /dev/sdc
> > MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
> >
> > btrfs/265 2s ... 1s
> > Ran: btrfs/265
> > Passed all 1 tests
> >
> > root 13:31:02 /home/fdmanana/git/hub/xfstests > ./check btrfs/265
> > FSTYP -- btrfs
> > PLATFORM -- Linux/x86_64 debian0 6.14.0-rc4-btrfs-next-188+ #1
> > SMP PREEMPT_DYNAMIC Wed Feb 26 17:38:41 WET 2025
> > MKFS_OPTIONS -- /dev/sdc
> > MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
> >
> > btrfs/265 1s ... - output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad)
> > --- tests/btrfs/265.out 2023-03-02 21:47:53.876609426 +0000
> > +++ /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad
> > 2025-02-27 13:31:05.522911416 +0000
> > @@ -5,38 +5,38 @@
> > step 2......corrupt file extent
> > step 3......repair the bad copy
> > step 4......check if the repair worked
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> > ................
> > ...
> > (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/265.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/265.out.bad' to see
> > the entire diff)
> > Ran: btrfs/265
> > Failures: btrfs/265
> > Failed 1 of 1 tests
> >
> > root 13:31:05 /home/fdmanana/git/hub/xfstests >
> >
> > Bisection using 100 iterations reliably points to that commit.
> >
> > Any ideas Darrick?
> >
> > Thanks.
> >
> >
> >
> > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> > > [af0f1090e240] common/rc: don't copy fsstress to $TEST_DIR
> > > [f43da58ef936] unmount: resume logging of stdout and stderr for filtering
> > > [5dc27fd20f80] mkfs: don't hardcode log size
> > > [dba402b7e3ae] common/rc: return mount_ret in _try_scratch_mount
> > > [9505d04b8073] preamble: fix missing _kill_fsstress
> > > [4d9aeeb79f9c] generic/650: revert SOAK DURATION changes
> > > [1bb15a27573e] generic/032: fix pinned mount failure
> > > [b816737426bf] fuzzy: stop __stress_scrub_fsx_loop if fsx fails
> > > [040e74c89192] fuzzy: don't use readarray for xfsfind output
> > > [0dfe1fac98d2] fuzzy: always stop the scrub fsstress loop on error
> > > [336d73c96a96] fuzzy: port fsx and fsstress loop to use --duration
> > > [96d29207c126] fix _require_scratch_duperemove ordering
> > > [a8268531ca8b] fsstress: fix a memory leak
> > > [e8e29e028faa] fsx: fix leaked log file pointer
> > > [4a9e82863917] misc: don't put nr_cpus into the fsstress -n argument
> > > [c475ff6ff6d7] common/config: add $here to FSSTRESS_PROG
> > > [1c67e8b191fe] config: add FSX_PROG variable
> > > [a553e7eba1cf] build: initialize stack variables to zero by default
> > >
> > > David Sterba (2):
> > > [9049250b4042] fstests: remove ltp/growfiles
> > > [5b56a2d88819] fstests: remove reiserfs support
> > >
> > > Filipe Manana (2):
> > > [7122c0315a08] btrfs/254: don't leave mount on test fs in case of failure/interruption
> > > [535b72a63a28] btrfs/254: fix test failure in case scratch devices are larger than 50G
> > >
> > > Jeff Layton (1):
> > > [bd6e01c81e21] generic/126: run it inside its own subdirectory
> > >
> > >
> > > Code Diffstat:
> > >
> > > .gitignore | 1 -
> > > Makefile | 2 +-
> > > check | 91 +-
> > > common/config | 12 +-
> > > common/dump | 1 -
> > > common/fuzzy | 104 +-
> > > common/metadump | 42 +-
> > > common/populate | 13 +-
> > > common/preamble | 2 +-
> > > common/quota | 6 +-
> > > common/rc | 146 ++-
> > > common/reflink | 2 +-
> > > configure.ac | 1 +
> > > include/builddefs.in | 3 +-
> > > lib/tlibio.c | 2 +-
> > > ltp/Makefile | 2 +-
> > > ltp/fsstress.c | 1 +
> > > ltp/fsx.c | 8 +-
> > > ltp/growfiles.c | 2607 -------------------------------------------------
> > > m4/package_libcdev.m4 | 14 +
> > > src/nsexec.c | 18 +-
> > > src/xfsfind.c | 14 +-
> > > tests/btrfs/254 | 8 +-
> > > tests/generic/019 | 2 +-
> > > tests/generic/032 | 9 +
> > > tests/generic/050 | 2 +-
> > > tests/generic/075 | 2 +-
> > > tests/generic/085 | 2 +-
> > > tests/generic/093 | 2 +-
> > > tests/generic/112 | 2 +-
> > > tests/generic/125 | 2 +-
> > > tests/generic/126 | 17 +-
> > > tests/generic/127 | 16 +-
> > > tests/generic/128 | 2 +-
> > > tests/generic/193 | 36 +-
> > > tests/generic/230 | 14 +-
> > > tests/generic/231 | 4 +-
> > > tests/generic/233 | 2 +-
> > > tests/generic/270 | 12 +-
> > > tests/generic/310 | 6 +-
> > > tests/generic/314 | 2 +-
> > > tests/generic/327 | 2 +-
> > > tests/generic/328 | 4 +-
> > > tests/generic/355 | 2 +-
> > > tests/generic/361 | 4 +-
> > > tests/generic/370 | 10 +-
> > > tests/generic/453 | 6 +-
> > > tests/generic/455 | 2 +-
> > > tests/generic/456 | 2 +-
> > > tests/generic/457 | 2 +-
> > > tests/generic/469 | 2 +-
> > > tests/generic/476 | 4 +-
> > > tests/generic/499 | 2 +-
> > > tests/generic/504 | 15 +-
> > > tests/generic/511 | 2 +-
> > > tests/generic/514 | 2 +-
> > > tests/generic/530 | 6 +-
> > > tests/generic/531 | 6 +-
> > > tests/generic/561 | 2 +-
> > > tests/generic/573 | 2 +-
> > > tests/generic/590 | 2 +-
> > > tests/generic/600 | 2 +-
> > > tests/generic/601 | 2 +-
> > > tests/generic/603 | 10 +-
> > > tests/generic/642 | 2 +-
> > > tests/generic/650 | 6 +-
> > > tests/generic/673 | 2 +-
> > > tests/generic/674 | 2 +-
> > > tests/generic/675 | 2 +-
> > > tests/generic/680 | 2 +-
> > > tests/generic/681 | 2 +-
> > > tests/generic/682 | 2 +-
> > > tests/generic/683 | 2 +-
> > > tests/generic/684 | 2 +-
> > > tests/generic/685 | 2 +-
> > > tests/generic/686 | 2 +-
> > > tests/generic/687 | 2 +-
> > > tests/generic/688 | 2 +-
> > > tests/generic/691 | 8 +-
> > > tests/generic/721 | 10 +-
> > > tests/generic/726 | 2 +-
> > > tests/generic/727 | 2 +-
> > > tests/generic/740 | 2 +-
> > > tests/generic/746 | 2 +-
> > > tests/generic/750 | 2 +-
> > > tests/generic/759 | 7 +-
> > > tests/generic/760 | 7 +-
> > > tests/xfs/149 | 2 +-
> > > tests/xfs/501 | 2 +-
> > > tests/xfs/502 | 2 +-
> > > tests/xfs/530 | 2 +-
> > > tests/xfs/720 | 2 +-
> > > tests/xfs/795 | 2 +-
> > > tests/xfs/803 | 2 +-
> > > tools/Makefile | 21 +
> > > tools/run_privatens | 28 +
> > > tools/run_setsid | 22 +
> > > 97 files changed, 596 insertions(+), 2890 deletions(-)
> > > --
> > > Zorro Lang
> > > zlang@kernel.org
> >
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23
2025-03-01 16:50 ` Zorro Lang
@ 2025-03-04 18:58 ` Darrick J. Wong
0 siblings, 0 replies; 23+ messages in thread
From: Darrick J. Wong @ 2025-03-04 18:58 UTC (permalink / raw)
To: Zorro Lang; +Cc: David Sterba, Zorro Lang, fstests
On Sun, Mar 02, 2025 at 12:50:12AM +0800, Zorro Lang wrote:
> On Fri, Feb 28, 2025 at 01:33:54PM +0100, David Sterba wrote:
> > On Sun, Feb 23, 2025 at 08:27:43PM +0800, Zorro Lang wrote:
> > > Hi all,
> > >
> > > The for-next branch of the xfstests repository at:
> > >
> > > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> > >
> > > has just been updated and tagged as v2025.02.23 release.
> > >
> > > Release Notes:
> > > 1) There's not new test cases in this release, this's a release for bug fixes
> > > particularly.
> > > 2) Reiserfs part is removed from fstests.
> > > 3) ltp/growfiles is removed too, I think no one needs it.
> > >
> > > I can't list all updates at here, more details please refer to below.
> > > Thanks for all these contributions!
> > >
> > > Thanks,
> > > Zorro
> > >
> > > The new head of the for-next branch is commit:
> > >
> > > 5b56a2d88819 fstests: remove reiserfs support
> > >
> > > New commits:
> > >
> > > Christoph Hellwig (1):
> > > [04d0cf3f8909] generic/370: don't exclude XFS
> > >
> > > Darrick J. Wong (35):
> > > [cc379f50f3bd] generic/476: fix fsstress process management
> > > [ab459c67c5e0] metadump: make non-local function variables more obvious
> > > [f428edcec2a2] metadump: fix cleanup for v1 metadump testing
> > > [e68a92376165] generic/019: don't fail if fio crashes while shutting down
> > > [48a3731b50ba] fuzzy: do not set _FSSTRESS_PID when exercising fsx
> > > [543795bf67f2] common/rc: revert recursive unmount in _clear_mount_stack
> > > [777732b27e62] common/dump: don't replace pids arbitrarily
> > > [81f28acda2f2] common/populate: correct the parent pointer name creation formulae
> > > [9b177d92dc65] generic/759,760: fix MADV_COLLAPSE detection and inclusion
> > > [241c1c787e5b] generic/759,760: skip test if we can't set up a hugepage for IO
> > > [77548e6066fd] common/rc: create a wrapper for the su command
> > > [ac2d48f81094] fuzzy: kill subprocesses with SIGPIPE, not SIGINT
> > > [c71349150d34] common/rc: hoist pkill to a helper function
> > > [91d2880aa029] tools: add a Makefile
> > > [88d60f434bd9] common: fix pkill by running test program in a separate session
> > > [247ab01fa227] check: run tests in a private pid/mount namespace
> > > [949bdf8eae31] check: deprecate using process sessions to isolate test instances
> >
> > I'm using a setup with a minimal VM system without systemd and such and
> > dedicate the whole machine to one instance. I'm not interested in the
> > check-parallel updates and test case separation. All fine if it is
> > supported and lets me continue using single instance.
> >
> > But as I read it and the deprecation it's not going to be the supported
> > use case. After last week update of fstests 100% of cases failed in the
> > test setup (_seq_run). My workaround is to simply disable it by
> >
> > check:
> > HAVE_PRIVATENS=
> > HAVE_SYSTEMD_SCOPES=
>
> BTW, HAVE_SYSTEMD_SCOPES has been there several years, so if it works for
> you before, it's not the problem of HAVE_SYSTEMD_SCOPES, even if your VM
> doesn't have systemd.
>
> So if it works for you by setting HAVE_PRIVATENS=(null), then the problem
> maybe from the `./tools/run_privatens "./$seq"` part, and also means the
> `./tools/run_setsid "./$seq"` part is good to you. Sorry I didn't hit
> this failure even with btrfs, so if you can provide some details, we'll
> look into it.
Yes, the exact output of the test failure would help debug this. Did
the initial detection of private namespace support succeed, but then
actually running a test failed? Did something get screwed up once the
test was running? There have been other reports about odd problems if
TEST_DIR/SCRATCH_MNT point to something under /tmp.
(This is exactly why I didn't want to get involved in a land war
in^W^W^Wrefactoring of working bash code.)
--D
> Zorro
>
> >
> > so I don't have to debug changes to the detection of the scope and
> > namespaces and after each for-next update. I understand that with a
> > custom system setup I'm on my own but until recently things have been
> > fine but now after each update either test cases fail or the whole test
> > infrastructure does not work.
> >
> > It's not just me who observes that. It seems that BTRFS is not tested
> > before release as thoroughly as other filesystems (probably just XFS).
> >
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2025-03-04 18:58 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <67bb1448.500a0220.af3ac.9928SMTPIN_ADDED_BROKEN@mx.google.com>
2025-02-27 13:32 ` [ANNOUNCE] fstests: for-next branch updated to v2025.02.23 Filipe Manana
2025-02-27 17:52 ` Darrick J. Wong
2025-02-28 11:54 ` David Sterba
2025-03-01 17:22 ` Zorro Lang
2025-03-04 18:37 ` Darrick J. Wong
2025-02-23 12:27 Zorro Lang
2025-02-23 19:30 ` Darrick J. Wong
2025-02-24 5:48 ` Zorro Lang
2025-02-24 22:04 ` Dave Chinner
2025-02-25 9:00 ` Zorro Lang
2025-02-28 12:33 ` David Sterba
2025-02-28 17:33 ` Darrick J. Wong
2025-03-01 1:01 ` Theodore Ts'o
2025-03-01 14:08 ` Zorro Lang
2025-03-02 13:13 ` Filipe Manana
2025-03-02 14:50 ` Theodore Ts'o
2025-03-02 16:18 ` Zorro Lang
2025-03-02 18:42 ` Filipe Manana
2025-03-02 15:37 ` Zorro Lang
2025-03-02 19:02 ` Filipe Manana
2025-03-02 19:56 ` Zorro Lang
2025-03-01 16:50 ` Zorro Lang
2025-03-04 18:58 ` Darrick J. Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox