Re: [linus:master] [xfs] ca6448aed4: xfstests.xfs.556.fail

[Zizhi Wo <wozizhi@xxxxxxxxxx>]

在 2024/9/3 17:16, Zizhi Wo 写道:
> Hi
>
> 在 2024/9/3 13:18, kernel test robot 写道:
> > Hello,
> >
> > kernel test robot noticed "xfstests.xfs.556.fail" on:
> >
> > commit: ca6448aed4f10ad88eba79055f181eb9a589a7b3 ("xfs: Fix missing 
> > interval for missing_owner in xfs fsmap")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >
> > [test failed on linus/master      
> > 431c1646e1f86b949fa3685efc50b660a364c2b6]
> > [test failed on linux-next/master 
> > 985bf40edf4343dcb04c33f58b40b4a85c1776d4]
> >
> > in testcase: xfstests
> > version: xfstests-x86_64-d9423fec-1_20240826
> > with following parameters:
> >
> >     disk: 4HDD
> >     fs: xfs
> >     test: xfs-556
> >
> >
> >
> > compiler: gcc-12
> > test machine: 4 threads Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz 
> > (Skylake) with 16G memory
> >
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> >
> >
> >
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new 
> > version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
> > | Closes: 
> > https://lore.kernel.org/oe-lkp/202409031358.2c34ad37-oliver.sang@xxxxxxxxx
> >
> > 2024-09-01 09:27:55 export TEST_DIR=/fs/sda1
> > 2024-09-01 09:27:55 export TEST_DEV=/dev/sda1
> > 2024-09-01 09:27:55 export FSTYP=xfs
> > 2024-09-01 09:27:55 export SCRATCH_MNT=/fs/scratch
> > 2024-09-01 09:27:55 mkdir /fs/scratch -p
> > 2024-09-01 09:27:55 export SCRATCH_DEV=/dev/sda4
> > 2024-09-01 09:27:55 export SCRATCH_LOGDEV=/dev/sda2
> > 2024-09-01 09:27:55 export 
> > SCRATCH_XFS_LIST_METADATA_FIELDS=u3.sfdir3.hdr.parent.i4
> > 2024-09-01 09:27:55 export SCRATCH_XFS_LIST_FUZZ_VERBS=random
> > 2024-09-01 09:27:55 echo xfs/556
> > 2024-09-01 09:27:55 ./check xfs/556
> > FSTYP         -- xfs (debug)
> > PLATFORM      -- Linux/x86_64 lkp-skl-d06 
> > 6.11.0-rc5-00007-gca6448aed4f1 #1 SMP PREEMPT_DYNAMIC Sun Sep  1 
> > 16:52:26 CST 2024
> > MKFS_OPTIONS  -- -f /dev/sda4
> > MOUNT_OPTIONS -- /dev/sda4 /fs/scratch
> >
> > xfs/556       - output mismatch (see 
> > /lkp/benchmarks/xfstests/results//xfs/556.out.bad)
> >      --- tests/xfs/556.out    2024-08-26 19:09:50.000000000 +0000
> >      +++ /lkp/benchmarks/xfstests/results//xfs/556.out.bad    
> > 2024-09-01 09:28:17.532120817 +0000
> >      @@ -1,12 +1,21 @@
> >       QA output created by 556
> >       Scrub for injected media error (single threaded)
> >      +Corruption: disk offset 106496: media error in unknown owner. 
> > (phase6.c line 400)
> >       Unfixable Error: SCRATCH_MNT/a: media error at data offset 2FSB 
> > length 1FSB.
> >       SCRATCH_MNT: unfixable errors found: 1
> >      +SCRATCH_MNT: corruptions found: 1
> >      +SCRATCH_MNT: Unmount and run xfs_repair.
> >      ...
> >      (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/556.out 
> > /lkp/benchmarks/xfstests/results//xfs/556.out.bad'  to see the entire 
> > diff)
> > Ran: xfs/556
> > Failures: xfs/556
> > Failed 1 of 1 tests
> >
> >
> >
> >
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20240903/202409031358.2c34ad37-oliver.sang@xxxxxxxxx
>
> I attempted to reproduce the issue using the script provided in this
> link: 
> https://download.01.org/0day-ci/archive/20240903/202409031358.2c34ad37-oliver.sang@xxxxxxxxx/repro-script.
> but I discovered that it might not be related to my patch. After I
> reverted my own fsmap-related patches locally and ran the test case
> using this script, it still failed.
>
> I'm not sure if it's due to an issue with my own environment or if there
> are other factors I haven't considered.
>
> However, I still found the current problems of fsmap, and I am not sure
> whether it is related to these two.[1][2]
>
> [1] 
> https://lore.kernel.org/all/550c038b-d931-4d00-9ebd-5c903e5ddf07@xxxxxxxxxx/
> [2] 
> https://lore.kernel.org/all/20240826031005.2493150-1-wozizhi@xxxxxxxxxx/

However, I noticed that if I make the changes mentioned in [1], the
local error message becomes consistent with the one observed without
this patch applied. I'm not certain if this aligns with the expected
behavior.

> Thanks,
> Zizhi Wo
>
> >