FSTests Archive on lore.kernel.org
 help / color / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: fstests@vger.kernel.org, linux-xfs@vger.kernel.org, zlang@redhat.com
Subject: Re: [PATCH v3] xfstests: xfs mount option sanity test
Date: Mon, 27 Jan 2020 08:57:28 -0800
Message-ID: <20200127165728.GA3448165@magnolia> (raw)
In-Reply-To: <20200119072342.GH14282@dhcp-12-102.nay.redhat.com>

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:

	$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"

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  8:11 Zorro Lang
2020-01-18 17:23 ` Darrick J. Wong
2020-01-19  7:23   ` Zorro Lang
2020-01-27 16:57     ` Darrick J. Wong [this message]
2020-01-29  5:23       ` Zorro Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200127165728.GA3448165@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

FSTests Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/fstests/0 fstests/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 fstests fstests/ https://lore.kernel.org/fstests \
		fstests@vger.kernel.org
	public-inbox-index fstests

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.fstests


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git