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
