On Sun, Jan 19, 2020 at 03:23:42PM +0800, Zorro Lang wrote: > On Sat, Jan 18, 2020 at 09:23:30AM -0800, Darrick J. Wong wrote: > > On Wed, Jan 15, 2020 at 04:11:32PM +0800, Zorro Lang wrote: > > > XFS is changing to suit the new mount API, so add this case to make > > > sure the changing won't bring in regression issue on xfs mount option > > > parse phase, and won't change some default behaviors either. > > > > > > Signed-off-by: Zorro Lang <zlang@xxxxxxxxxx> > > > --- > > > > > > Hi, > > > > > > Thanks the suggestions from Darrick, v3 did below changes: > > > 1) Add more debug info output in do_mkfs and do_test. > > > 2) A new function filter_loop. > > > 3) Update .out file content > > > > > > I've simply run this case on RHEL-7, RHEL-8 and upstream 5.5-rc4 kernel, > > > all passed. > > > > Something else I noticed -- if for whatever reason the mount fails due > > to log size checks, the kernel logs things like: > > > > xfs: Bad value for 'logbufs' > > XFS (loop0): Mounting V5 Filesystem > > XFS (loop0): Log size 3273 blocks too small, minimum size is 3299 blocks > > XFS (loop0): AAIEEE! Log failed size checks. Abort! > > XFS: Assertion failed: 0, file: fs/xfs/xfs_log.c, line: 706 > > Thanks Darrick, you always can find exceptions:) BTW, how to reproduce this > error? It's the same problem as last time -- I run upstream xfsprogs (with the patch turning on rmap by default); and when this test runs apparently there are logbufs options that increase the kernel's view of the minimum log size to the point that we fail the mount time log size checks. I observed that changing the LOOP_IMG creation code to make a 32G sparse file results in an fs with a larger log area: $XFS_IO_PROG -f -c "truncate 32g" $LOOP_IMG fixes all of these problems. See diff below. > Looks like I touched too many things in one case, cause I have a long way to > make it "no exception" ;) > > > > > Which is then picked up by the dmesg scanner in fstests. Maybe we need > > (a) _check_dmesg between each _do_test iteration, and/or (b) filter that > > particular assertion so we don't fail the test? > > I can add _check_dmesg between each _do_test iteration, but I have to exit > directly if _check_dmesg returns 1, or we need a way to save each failed > $seqres.dmesg (maybe just cat $seqres.dmesg ?) > > About the dmesg filter, each _do_test can have its own filter if it need. > For example, "logbufs" test filter "Assertion failed: 0, file: fs/xfs/xfs_log.c". > But might that filter out useful kernel warning? > > What do you think? Eh, now that I've taken a second look at this, I don't think there's a good way to filter this particular ASSERT vs. any other that could pop up. --D diff --git a/tests/xfs/997 b/tests/xfs/997 index 6b7235dd..c5bb0e51 100755 --- a/tests/xfs/997 +++ b/tests/xfs/997 @@ -50,11 +50,11 @@ LOOP_SPARE_IMG=$TEST_DIR/$seq.logdev LOOP_MNT=$TEST_DIR/$seq.mnt echo "** create loop device" -$XFS_IO_PROG -f -c "falloc 0 1g" $LOOP_IMG +$XFS_IO_PROG -f -c "truncate 32g" $LOOP_IMG LOOP_DEV=`_create_loop_device $LOOP_IMG` echo "** create loop log device" -$XFS_IO_PROG -f -c "falloc 0 512m" $LOOP_SPARE_IMG +$XFS_IO_PROG -f -c "truncate 512m" $LOOP_SPARE_IMG LOOP_SPARE_DEV=`_create_loop_device $LOOP_SPARE_IMG` echo "** create loop mount point"
