From: Frederic Weisbecker on 2 Jan 2010 21:00 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 2 Jan 2010 21:10 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 2 Jan 2010 22:30 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 4 Jan 2010 15:30 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/
First
|
Prev
|
Pages: 1 2 3 4 Prev: [PATCH -next] libs: force lzma_wrapper to be retained Next: staging Patch 02/03: Crystal HD |