From: Frederic Weisbecker on
On Sat, Jan 02, 2010 at 06:36:03PM -0500, tytso(a)mit.edu wrote:
> Yes, quite a bit more than that. One such test (which is used by
> xfsqa test) is the fsstress proram, which is quite flexible. You can
> program different combinations of fallocate, direct I/O read/writes,
> setxattr, buffered read/writes, symlinks, truncates, renames, etc..
>
> The xfsqa suite will run fsstress in a number of different modes, but
> that's not the only test program that it uses. It also uses the fsx
> program which exercises concurrent read/write/mmap operations, as well
> as other programs to test acl support, noatime support, etc.
>
> I make a point of running the regression test suite before pushing a
> patch series to Linus; it makes me far more comfortable than I haven't
> accidentally introduced some problem.



Hmm, I'm trying to play with it, and some things are not obvious to
me. I can launch fsstress directly, works well, but as I would
like to run all possible tests, I'm trying the check script, as
explained in the README file.

So I've set the partition and ran the script:

export TEST_DEV=/dev/sda3
../check -r

But:

[: 53: ==: unexpected operator
common.rc: Error: $TEST_DEV (/dev/sda3) is not a MOUNTED xfs filesystem
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda3 reiserfs 134797288 2982296 131814992 3% /data


I'm not sure how I can run these tests on a non-xfs partitions.
I must be missing something.


> > I guess this is the right place to get it?
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> Yep. You'll need to install a number of packages to compile it,
> including libaio-dev, libattr1-dev, libacl1-dev, xfsprogs,
> xfslibs-dev, etc.


Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christian Kujau on
On Sun, 3 Jan 2010 at 02:52, Frederic Weisbecker wrote:
> [: 53: ==: unexpected operator
> common.rc: Error: $TEST_DEV (/dev/sda3) is not a MOUNTED xfs filesystem

Yeah, I'm playing around with xfstests as well, but apparently they're
assuming !/bin/sh will be run under /bin/bash, which is not always the
case. A short fix is to link /bin/sh to /bin/bash, but perhaps some of the
tests can be tweaked to run under /bin/sh as well.

> I'm not sure how I can run these tests on a non-xfs partitions.
> I must be missing something.

I haven't found an easy way to do this yet without rewriting a few
routines (mkfs, mount, etc...). As Ted is already using xfstests for
btrfs, ext4, maybe he wants to share his magic? :-)

Christian.
--
BOFH excuse #47:

Complete Transient Lockout
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: tytso on
On Sat, Jan 02, 2010 at 06:05:13PM -0800, Christian Kujau wrote:
> On Sun, 3 Jan 2010 at 02:52, Frederic Weisbecker wrote:
> > [: 53: ==: unexpected operator
> > common.rc: Error: $TEST_DEV (/dev/sda3) is not a MOUNTED xfs filesystem
>
> Yeah, I'm playing around with xfstests as well, but apparently they're
> assuming !/bin/sh will be run under /bin/bash, which is not always the
> case. A short fix is to link /bin/sh to /bin/bash, but perhaps some of the
> tests can be tweaked to run under /bin/sh as well.
>
> > I'm not sure how I can run these tests on a non-xfs partitions.
> > I must be missing something.
>
> I haven't found an easy way to do this yet without rewriting a few
> routines (mkfs, mount, etc...). As Ted is already using xfstests for
> btrfs, ext4, maybe he wants to share his magic? :-)

I'm using it for ext4. It looks like someone has already tried using
the xfstests with reiserfs; take a look at common.rc; you'll see case
statements for xfs, udf, nfs, ext2/3/4, reiserfs, and gfs2. Someone
who wants to use xfstests for some other file system may need to
further edit common.rc. I thought the btrfs folks were using it as
well, but at least the kernel.org git tree for xfstests doesn't seem
to show any btrfs references in common.rc, so perhaps I'm wrong about
btrfs developers using xfstests (or they haven't sent their patches
back upstream). I'm not sure how well tested the reiserfs support is,
so you may need to edit common.rc as necessary.

In any case, the README file has pretty much what you need. I
personally run my test kernels using KVM, and I have a run-test script
which invokes check as follows:

#!/bin/sh
export TEST_DEV=/dev/sdb
export TEST_DIR=/test
export SCRATCH_DEV=/dev/sdc1
export SCRATCH_MNT=/scratch
export EXT_MOUNT_OPTIONS="-o block_validity"
exec ./check -ext4 $*

/dev/sdb is an ext4-formated filesystem, which you're supposed to not
reformat from run to run, so that some testing can be done with an
"aged" file system. The scratch filesystem will be reformatted for
various tests, so you shouldn't keep anything valueable on it.

I also have a 1k block file system on /dev/sdd, so I invoke check as
follows to check to make sure things work when blocksize != pagesize:

#!/bin/sh
export TEST_DEV=/dev/sdd
export TEST_DIR=/test-1k
export SCRATCH_DEV=/dev/sdc1
export SCRATCH_MNT=/scratch
export MKFS_OPTIONS="-b 1024"
exec ./check -ext4 $*

As far as the inconsistency between TEST_DIR versus SCRATCH_MNT ---
all I can say is, the XFS engineers who threw together the xfstests
scripts may have been very good file system engineers, but they
obviously weren't very well used as UI/User Experience designers. :-)
(The documentation isn't all that great either, but patches sent to
xfs(a)oss.sgi.com do tend to be accepted and merged into the kernel.org
tree if they are clean.)

Hope this helps,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on
On Sat, Jan 02, 2010 at 10:27:58PM -0500, tytso(a)mit.edu wrote:
> On Sat, Jan 02, 2010 at 06:05:13PM -0800, Christian Kujau wrote:
> > On Sun, 3 Jan 2010 at 02:52, Frederic Weisbecker wrote:
> > > [: 53: ==: unexpected operator
> > > common.rc: Error: $TEST_DEV (/dev/sda3) is not a MOUNTED xfs filesystem
> >
> > Yeah, I'm playing around with xfstests as well, but apparently they're
> > assuming !/bin/sh will be run under /bin/bash, which is not always the
> > case. A short fix is to link /bin/sh to /bin/bash, but perhaps some of the
> > tests can be tweaked to run under /bin/sh as well.
> >
> > > I'm not sure how I can run these tests on a non-xfs partitions.
> > > I must be missing something.
> >
> > I haven't found an easy way to do this yet without rewriting a few
> > routines (mkfs, mount, etc...). As Ted is already using xfstests for
> > btrfs, ext4, maybe he wants to share his magic? :-)
>
> I'm using it for ext4. It looks like someone has already tried using
> the xfstests with reiserfs; take a look at common.rc; you'll see case
> statements for xfs, udf, nfs, ext2/3/4, reiserfs, and gfs2. Someone
> who wants to use xfstests for some other file system may need to
> further edit common.rc. I thought the btrfs folks were using it as
> well, but at least the kernel.org git tree for xfstests doesn't seem
> to show any btrfs references in common.rc, so perhaps I'm wrong about
> btrfs developers using xfstests (or they haven't sent their patches
> back upstream). I'm not sure how well tested the reiserfs support is,
> so you may need to edit common.rc as necessary.
>
> In any case, the README file has pretty much what you need. I
> personally run my test kernels using KVM, and I have a run-test script
> which invokes check as follows:
>
> #!/bin/sh
> export TEST_DEV=/dev/sdb
> export TEST_DIR=/test
> export SCRATCH_DEV=/dev/sdc1
> export SCRATCH_MNT=/scratch
> export EXT_MOUNT_OPTIONS="-o block_validity"
> exec ./check -ext4 $*
>
> /dev/sdb is an ext4-formated filesystem, which you're supposed to not
> reformat from run to run, so that some testing can be done with an
> "aged" file system. The scratch filesystem will be reformatted for
> various tests, so you shouldn't keep anything valueable on it.
>
> I also have a 1k block file system on /dev/sdd, so I invoke check as
> follows to check to make sure things work when blocksize != pagesize:
>
> #!/bin/sh
> export TEST_DEV=/dev/sdd
> export TEST_DIR=/test-1k
> export SCRATCH_DEV=/dev/sdc1
> export SCRATCH_MNT=/scratch
> export MKFS_OPTIONS="-b 1024"
> exec ./check -ext4 $*



Ok. Thanks a lot for all these details. It seems to be working
now that I have edited some shebang and replaced /bin/sh by
/bin/bash, like Christopher suggested.



> As far as the inconsistency between TEST_DIR versus SCRATCH_MNT ---
> all I can say is, the XFS engineers who threw together the xfstests
> scripts may have been very good file system engineers, but they
> obviously weren't very well used as UI/User Experience designers. :-)



Agreed :)



> (The documentation isn't all that great either, but patches sent to
> xfs(a)oss.sgi.com do tend to be accepted and merged into the kernel.org
> tree if they are clean.)
>
> Hope this helps,


Yeah, thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/