Re: [PATCH V6 13/13] xfs: Stress test with bmap_alloc_minlen_extent error tag enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 26, 2021 at 09:35:33AM +0530, Chandan Babu R wrote:
> On 23 Mar 2021 at 10:58, Chandan Babu R wrote:
> > On 23 Mar 2021 at 00:24, Darrick J. Wong wrote:
> >> On Tue, Mar 09, 2021 at 10:31:24AM +0530, Chandan Babu R wrote:
> >>> This commit adds a stress test that executes fsstress with
> >>> bmap_alloc_minlen_extent error tag enabled.
> >>
> >> Continuing along the theme of watching the magic smoke come out when dir
> >> block size > fs block size, I also observed the following assertion when
> >> running this test:
> 
> Apart from "xfs_dir2_shrink_inode only calls xfs_bunmapi once" bug, I
> noticed that scrub has detected metadata inconsistency,
> 
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 debian-guest 5.12.0-rc4-chandan #30 SMP Thu Mar 25 11:00:08 IST 2021
> MKFS_OPTIONS  -- -f -b size=1k -m rmapbt=0,reflink=0 -n size=64k /dev/vdc2
> MOUNT_OPTIONS -- /dev/vdc2 /mnt/scratch
> 
> xfs/538 43s ... _check_xfs_filesystem: filesystem on /dev/vdc2 failed scrub
> (see /root/repos/xfstests-dev/results//xfs/538.full for details)
> 
> Ran: xfs/538
> Failures: xfs/538
> Failed 1 of 1 tests
> 
> I will work on fixing this one as well.

Yeah, I noticed that too.  There are two bugs -- the first one is that
the "Block directories only have a single block at offset 0" check in
xchk_directory_blocks is wrong -- they can have a single *dir* block at
offset 0.  The correct check is (I think):

	if (is_block && got.br_startoff >= args.geo->fsbcount) {
		xchk_fblock_set_corrupt(...);
		break;
	}

The second problem is ... somewhere in the bmbt scrubber.  It looks like
there's a file with a data fork in btree format; the data fork has a
single child block; and there are few enough key/ptrs in that child
block that it /could/ fit in the root.  For some reason the btree code
didn't promote it, however.  Seeing as nobody's touched that code
lately, that probably means that scrub is wrong, but OTOH that /does/
seem like a waste of a block.

But, that's as far as I've gotten on that second one and it's late.
Thanks for taking a look! :)

--D

> -- 
> chandan



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux