On Wed, Apr 17, 2024 at 02:48:16PM +1000, Dave Chinner wrote:
> On Tue, Apr 16, 2024 at 04:51:08PM -0700, Luis Chamberlain wrote:
> > This test is rather simple, and somehow we managed to capture a
> > non-crash failure. The test was added to fstests via fstests commit
> > 0c95fadc35c8e450 ("expand 252 with more corner case tests") which
> > essentially does this:
> >
> > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \
> > + -c "pwrite 0 $block_size" $sync_cmd \
> > + -c "$zero_cmd 128 128" \
> > + -c "$map_cmd -v" $testfile | $filter_cmd
> >
> > The map_cmd in this case is: 'bmap -p'. So the test does:
> >
> > a) truncates data to the block size
> > b) sync
> > c) zero-fills the the blocksize
> >
> > The xfs_io bmap displays the block mapping for the current open file.
> > Since our failed delta is:
> >
> > -0: [0..7]: data
> > +0: [0..7]: unwritten
>
> That's most likely a _filter_bmap() issue, not a kernel code bug.
>
> i.e. 'bmap -vp' output looks like:
>
> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> 0: [0..231]: 2076367680..2076367911 18 (6251328..6251559) 232 000000
>
> and _filter_bmap has two separate regex matches against different
> fields that both trigger "unwritten" output. The first check is
> against field 5 which is actually the AG-OFFSET in this output, not
> field 7 which is the FLAGS field.
>
> Hence if the ag offset matches '/0[01][01][01][01]/' the filter will
> emit 'unwritten' regardless of what the flags say it actually is.
>
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
I got a similar failure in xfs/242 as follows. It can be easily reproduced
when I run xfs/242 as a cyclic test. The root cause, as Dave pointed out,
is that _filter_bmap first matches the data in column 5, which may be
incorrect. On the other hand, _filter_bmap seems to be missing "next" to
jump out when it matches "data" in the 5th column, otherwise it might
print the result twice. The issue was introduced by commit 7d5d3f77154e
("xfs/242: fix _filter_bmap for xfs_io bmap that does rt file properly").
The failure disappeared when I retest xfs/242 by reverted commit 7d5d3f77154e.
The problem is not fixed yet. How about matching the 7th column first
and then the 5th column in _filter_bmap? because the rtdev file only has
5 columns in the `bmap -vp` output.
Best Regards,
Long Li
----------------------------------------------------------------------------
FSTYP -- xfs (debug)
PLATFORM -- Linux/aarch64 localhost 6.6.0+ #84 SMP Tue Jul 9 23:35:56 CST 2024
VMIP -- 192.168.250.78
MKFS_OPTIONS -- -f -m crc=1,rmapbt=0,reflink=0 /dev/sdb
MOUNT_OPTIONS -- /dev/sdb /tmp/scratch
xfs/242 1s ... - output mismatch (see /root/xfstests-dev/results//xfs/242.out.bad)
--- tests/xfs/242.out 2024-06-06 19:08:46.677638130 +0800
+++ /root/xfstests-dev/results//xfs/242.out.bad 2024-07-11 02:24:35.337554580 +0800
@@ -57,8 +57,7 @@
1aca77e2188f52a62674fe8a873bdaba
13. data -> unwritten -> data
0: [0..127]: data
-1: [128..511]: unwritten
-2: [512..639]: data
+1: [128..639]: unwritten
0bcfc7652751f8fe46381240ccadd9d7
...
(Run 'diff -u /root/xfstests-dev/tests/xfs/242.out /root/xfstests-dev/results//xfs/242.out.bad' to see the entire diff)
Ran: xfs/242
Failures: xfs/242
Failed 1 of 1 tests
