* 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-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 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
* [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 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-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 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 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 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-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-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