On 02/05/2018 04:04 PM, Darrick J. Wong wrote: > 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@xxxxxxxxx >>> >>>> # 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. xfsprogs-4.12.0-4.fc27.x86_64 > > --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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
