Re: [PATCH v3] xfstests: xfs mount option sanity test

[Zorro Lang <zlang@redhat.com>]

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@redhat.com>
> > > > ---
> > > > 
> > > > 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"
>