FSTests Archive on lore.kernel.org
 help / color / Atom feed
From: Zorro Lang <zlang@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3] xfstests: xfs mount option sanity test
Date: Wed, 29 Jan 2020 13:23:10 +0800
Message-ID: <20200129052310.GJ14282@dhcp-12-102.nay.redhat.com> (raw)
In-Reply-To: <20200127165728.GA3448165@magnolia>

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


      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
2020-01-29  5:23       ` Zorro Lang [this message]

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=20200129052310.GJ14282@dhcp-12-102.nay.redhat.com \
    --to=zlang@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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