On 2/5/18 5:18 PM, Dave Jiang wrote:
>
>
> 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
This hit 4.14:
commit 921c30674e9bc719e7c2747deb6deb04be2adb4b
Author: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Date: Thu Nov 9 11:35:22 2017 -0600
db: increase metadump's default overly long extent discard threshold
Back in 88b8e1d6d7 ("Make xfs_metadump more robust against bad data"),
metadump grew the ability to ignore a directory extent if it was longer
than 20 blocks. Presumably this was to protect metadump from dumping
absurdly long extents resulting from bmbt corruption, but it's certainly
possible to create a directory with an extent longer than 20 blocks.
Hilariously, the discards happen with no warning unless the caller
explicitly set -w.
This was raised to 1000 blocks in 7431d134fe8 ("Increase default maximum
extent size for xfs_metadump when copying..."), but it's still possible
to create a directory with an extent longer than 1000 blocks.
Increase the threshold to MAXEXTLEN blocks because it's totally valid
for the filesystem to create extents up to that length.
Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Reviewed-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxxx>
Usually best to run latest xfsprogs esp. for xfstests testing; while xfsprogs
is usually very stable, corner cases do get added to xfstests as they are fixed
and so you're likely to run into failures on new tests like this.
(Or to put a finer point on it, the test you failed on is something which is
specifically testing the fix above).
-Eric
--
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
