On Tue, Jun 17, 2014 at 08:41:05AM -0500, scameron@xxxxxxxxxxxxxxxxxx wrote:
> I am running xfstests mostly just to exercise a low level driver, and I'm
> seeing failures on tests xfs/122 and xfs/253.
> I'm using xfstests, xfsprogs, xfsdump cloned fresh from the git repos listed
> here: http://xfs.org/index.php/Getting_the_latest_source_code
> git hashes:
> xfstests: 45d1fac1303acfa102384f48111dc3a458b93493
> xfsprogs: 03e956b25243bf4aac034275f89a0f3f2712b79a
> xfsdump: b1d6979f1fae82acc79d27cf0add4d55da6d83cc
> I'm using kernel 3.16-rc1 on RHEL 6.5 on x86_64.
> I would expect that specific versions of xfstests, xfsprogs, xfsdump
> are meant to go with specific kernel versions, though it is not clear
> to me how to match these up in the general case. I guessed that
> "latest of everything" would have a reasonable chance of being a
> matched set.
> I'm running it by: "./check -g auto"
> with configs/localhost.config:
> [root@localhost xfstests]# cat configs/localhost.config
> I'm not very familiar with these tests, but it looks like xfs/122 is checking
> that some structure sizes specific to xfs are correct, and I'm struggling to
> see how a low level driver would break that test without breaking a lot of
> other stuff, so I'm thinking I can ignore that one (maybe the test is broken?)
> But I figured I should ask here in case I'm not correctly understanding what
> trying to test.
xfs/122 fails for me as well. I guess I never noticed it before because
it depends on indent. It looks like the output file (122.out) contains a
bunch of hardcoded field offsets and structure sizes, so perhaps it's
just out of date. I'm not familiar with the objective of this test.
> xfs/253, seems to be testing some kind of filename hashing stuff.
This one tests metadump and restore, name obfuscation in particular it
appears. It passes on a quick test for me with fairly recent code.
> Do these failures seem plausibly attributable to a flaw in a low level driver,
> or are these failures known issues with xfs or with the tests, or is there
> something else I might be doing wrong?
> (It occurs to me now I should try the tests with a different driver and
> hardware and see how it behaves.)
Probably a good idea. ;)
> [root@localhost xfs]# diff -u ../../tests/xfs/122.out 122.out.bad | diffstat
> 122.out.bad | 38 +++++++++++++++++++-------------------
> 1 file changed, 19 insertions(+), 19 deletions(-)
> [root@localhost xfs]# diff -u ../../tests/xfs/253.out 253.out.bad | diffstat
> 253.out.bad | 2 ++
> 1 file changed, 2 insertions(+)
> [root@localhost xfs]# diff -u ../../tests/xfs/253.out 253.out.bad
> --- ../../tests/xfs/253.out 2014-06-16 10:51:35.881521766 -0500
> +++ 253.out.bad 2014-06-16 18:01:13.862884730 -0500
> @@ -1,2 +1,4 @@
> QA output created by 253
> Disciplyne of silence is goed.
> +mount: Structure needs cleaning
> +umount: /dev/sdb: not mounted
> [root@localhost xfs]#
I'm guessing the dump or restore failed to properly create the metadump
image or restore it correctly. You probably want to try this on
something known to be working.
> Also, I noticed a few tests were not run, I presume that is not out of the
> xfs/189 [not run] noattr2 mount option not supported on /dev/sdb
> xfs/190 1s ... 1s
> xfs/191 [not run] no mkfs support for NFS v4 ACLs
> xfs/194 1s ... 1s
> xfs/195 [not run] fsgqa user not defined.
> xfs/196 5s ... 5s
> xfs/197 [not run] This test is only valid on 32 bit machines
> And a few others skipped as well.
This is generally normal. Tests will detect dependencies and/or settings
and skip running if not applicable as opposed to causing failures for
things that are problems with the test environment.
> -- steve
> xfs mailing list