Re: xfstests failures

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Mon, Feb 05, 2018 at 04:01:34PM -0700, Dave Jiang wrote:
> On 02/05/2018 03:31 PM, Dave Chinner wrote:
> > On Mon, Feb 05, 2018 at 02:40:40PM -0700, Dave Jiang wrote:
> >> Eryu,
> >> I've noticed that these tests fails under what I think is a normal
> >> config (BRD of 48G). We have an expectation that for simple configs all
> >> tests in the 'auto' group should pass, and these ones don't. Are these
> >> false positive failures?  If so, what do we need to do to remove these
> >> false positives?  a) fix the tests to handle these cases b) remove the
> >> tests from the 'auto' group?  Something else? Attached file with test
> >> outputs. I think some if not all of these failures have lasted many
> >> kernel versions.
> >>
> >> # xfs
> >> generic/009
> >> generic/012
> >> generic/016
> >> generic/021
> >> generic/022
> >> generic/058
> >> generic/060
> >> generic/061
> >> generic/063
> >> generic/092
> >> generic/255
> >> xfs/167
> >> xfs/191-input-validation
> >> xfs/242
> >> xfs/252
> >> xfs/432
> > 
> > Except for xfs/191, these all look to be extent mapping failures.
> > i.e. there's one bug or config issue that is causing them all.
> > 
> >> # ext4
> >> generic/388
> >>
> >>
> >> -- 
> >>
> >> Dave Jiang
> >> Software Engineer, SSG/OTC
> >> Intel Corp.
> >> dave.jiang@intel.com
> > 
> >> # XFS failures
> >>
> >> # ./check generic/009
> >> FSTYP         -- xfs (non-debug)
> >> PLATFORM      -- Linux/x86_64 skx-ntbusd 4.15.0+
> >> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram0p2
> >> MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/ram0p2 /mnt/xfstests_scratch
> >>
> >> generic/009	 - output mismatch (see /root/xfstests/xfstests-dev/results//generic/009.out.bad)
> >>     --- tests/generic/009.out	2016-09-09 09:30:36.006800609 -0700
> >>     +++ /root/xfstests/xfstests-dev/results//generic/009.out.bad	2018-02-05 13:24:23.702640408 -0700
> >>     @@ -1,79 +1,75 @@
> >>      QA output created by 009
> >>      	1. into a hole
> >>     -0: [0..7]: hole
> >>     -1: [8..23]: unwritten
> >>     -2: [24..39]: hole
> >>     +0: [0..4095]: unwritten
> > 
> > You're getting a 2MB extent allocated here. I'm guessing your
> > testdev is configured with a 2MB extent size hint or something
> > similar left over from trying to test DAX w/ 2MB huge pages?
> 
> Yes. Looks like the config script was setting 2M extent. After removing
> and retesting xfs/191 and xfs/432 fails.
> 
> 
> # ./check xfs/432
> FSTYP         -- xfs (non-debug)
> PLATFORM      -- Linux/x86_64 skx-ntbusd 4.15.0+
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram0p2
> MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/ram0p2
> /mnt/xfstests_scratch
> 
> xfs/432	 - output mismatch (see
> /root/xfstests/xfstests-dev/results//xfs/432.out.bad)
>     --- tests/xfs/432.out	2017-10-19 10:57:22.562819579 -0700
>     +++ /root/xfstests/xfstests-dev/results//xfs/432.out.bad	2018-02-05
> 15:57:29.673255360 -0700
>     @@ -3,4 +3,5 @@
>      Create huge dir
>      Check for > 1000 block extent?
>      Try to metadump
>     +xfs_metadump: suspicious count 1088 in bmap extent 1 in dir3 ino 35

What version of xfsprogs are you running?  I fixed that a while ago... I
think.

--D

>      Check restored metadump image
>     ...
>     (Run 'diff -u tests/xfs/432.out
> /root/xfstests/xfstests-dev/results//xfs/432.out.bad'  to see the entire
> diff)
> Ran: xfs/432
> Failures: xfs/432
> Failed 1 of 1 tests
> 
> 
> > 
> > Cheers,
> > 
> > Dave.
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html