>
> The second thing to be done is that downstream testers could use a script
> to auto-generate an expunge list for their test kernel, if they don't care about
> testing known issues, only regressions.
In my testing on RHEL (downstream), I record and update known issues, include known
failures and panic/hang issues (need to skip) for each RHEL release. Before running
xfstests, I try to get a skip list for a specified RHEL/kernel version. Then compare
with its known failures after testing done, to decide if a failure is known/unknown.
Also I created version tags for my redhat internal xfstests repo, for some downstream
of downstream kernel testing (likes Z-stream testing) can use fixed xfstests version.
Some known issue format I record as below[1], a bash script will help to parse it and
compare with testing results. It's only for our internal use, due to I think it's too
crude to be shared :-P
[1]
$ cat known_results/$distro/xfs/145.json
[
{
"DESCRIPTION": "bz19483*** XFS: Assertion failed: dqp->q_res_bcount >= be64_to_cpu(dqp->q_core.d_bcount)",
"FS": ["xfs"],
"DMESG": "Assertion failed: dqp->q_res_bcount >= be64_to_cpu\\(dqp->q_core.d_bcount\\)",
"FIXED": true
}
]
$ cat known_results/$distro/generic/417.json
[
{
"DESCRIPTION": "bz16255*** (<1%): XFS corruption attribute entry #0 in attr block 0, inode 674 is INCOMPLETE",
"FS": ["xfs"],
"ARCH": ["ppc64le"],
"OUTBAD": "_check_xfs_filesystem.*inconsistent",
"FULL": "attribute entry.*in attr block.*, inode.*is INCOMPLETE"
}
]
>
> I hope that with the new maintainship you will also take the opportunity
> to make fstests more friendly to downstream kernel testers.
>
> > All cases looks good, but according to the custom, all generic cases use
> > "_supported_fs generic", if you have 1+ specified filesystems, maybe
> > "tests/shared/*" is better?
> >
>
> I think we should stay away from tests/shared for as much as possible and
> use it only for very specific fs behaviors.
I prefer generic testing too :)
>
> What in the behavior of fallocate() and setgid makes it so special that it needs
> to be restricted to "xfs btrfs ext4" and not treated as a bug for other fs?
> I suspect that it might be difficult or impossible to change that behavior in
> network filesystems?
I'm not sure what other filesystems think about this behavior. If this's a standard
or most common behavior, I hope it can be a generic test (then let other fs maintainers
worry about their new testing failure:-P). Likes generic/673 was written for XFS,
then btrfs found failure, then btrfs said XFS should follow VFS as btrfs does :)
>
> When facing a similar dilemma in the past we ended up with a whitelist
> _fstyp_has_non_default_seek_data_hole(), but not sure we need to resort to that.
>
> Thanks,
> Amir.
>
