public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: scameron@beardog.cce.hp.com, xfs@oss.sgi.com
Subject: Re: Question about xfstests xfs/122 and xfs/253
Date: Wed, 18 Jun 2014 09:04:24 +1000	[thread overview]
Message-ID: <20140617230424.GK9508@dastard> (raw)
In-Reply-To: <20140617145717.GB8905@bfoster.bfoster>

On Tue, Jun 17, 2014 at 10:57:18AM -0400, Brian Foster wrote:
> 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.

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@fromorbit.com

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

      reply	other threads:[~2014-06-17 23:04 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
2014-06-17 23:04   ` Dave Chinner [this message]

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=20140617230424.GK9508@dastard \
    --to=david@fromorbit.com \
    --cc=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