On Tue, Jun 17, 2014 at 10:57:18AM -0400, Brian Foster wrote: > On Tue, Jun 17, 2014 at 08:41:05AM -0500, scameron@xxxxxxxxxxxxxxxxxx wrote: > > > > Hi, > > > > 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 > > TEST_DEV=/dev/sdc > > TEST_DIR=/mnt/test > > SCRATCH_DEV=/dev/sdb > > SCRATCH_MNT=/mnt/scratch > > > > 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 it's > > 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. They are the sizes and offsets of on-disk structures. I get a _not_run here because the test program fails to compile, which is probably why I've not noticed that it might be failing. I'll look into it that failure here. FWIW, posting the diff of the failure will tell us if it's an important failure or not, or whether it's just that we've removed a bunch of typedefs and so the program output is not exactly the same as expected.... > > 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 What's the dmesg output? > > xfs/189 [not run] noattr2 mount option not supported on /dev/sdb That implies you are testing with MKFS_OPTION="-m crc=1", because only CRC enabled filesystems reject the noattr2 mount option. Is that correct? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
