public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: scameron@beardog.cce.hp.com
Cc: xfs@oss.sgi.com
Subject: Re: Question about xfstests xfs/122 and xfs/253
Date: Tue, 17 Jun 2014 10:57:18 -0400	[thread overview]
Message-ID: <20140617145717.GB8905@bfoster.bfoster> (raw)
In-Reply-To: <20140617134105.GF29459@beardog.cce.hp.com>

On Tue, Jun 17, 2014 at 08:41:05AM -0500, scameron@beardog.cce.hp.com 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.

> 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 ordinary.
> 
> 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.

Brian

> Thanks,
> 
> -- steve
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-06-17 14:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 13:41 Question about xfstests xfs/122 and xfs/253 scameron
2014-06-17 14:57 ` Brian Foster [this message]
2014-06-17 23:04   ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140617145717.GB8905@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=scameron@beardog.cce.hp.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox