On Mon, Jan 27, 2020 at 08:57:28AM -0800, Darrick J. Wong wrote: > 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: Thanks, that's a good idea, sparse file helps to get larger log space! > > $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. Sure, I'm afraid to filter more real bugs, if there's not a good way to filter it. > > --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" >
