Re: xfstests failures

[Dave Jiang <dave.jiang@intel.com>]

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