Test 232 in the xfstests suite produces an XFS error in the log
when run over an RBD device. This is most likely an XFS problem
that will be tracked separately (in tracker 2302).
My original plan with getting this checked in was to have it run a
baseline set of the tests--all known to pass on rbd devices--with
the intention of doing ongoing work to add back missing tests (at
least from the "auto" group) as we understand and fix whatever
makes them produce failures.
So just comment out test 232 so the xfstests script is able to
run to completion without error.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Because we exit on any error (due to 'set -e'), the cleanup call was
never getting made in the event of an error. The net effect of that
was that a filesystem could be left mounted, and rbd cleanup then
couldn't complete because the module was in use.
Fix the trap call so it calls cleanup on exit as well as error.
Switch to using the capitalized signal names in the call.
Signed-off-by: Alex Elder <elder@dreamhost.com>
It turns out that xfstests *does* exit with non-zero status
when a test fails. Its exit status is the number of tests
that failed (which, now that we have over 255 tests could be
an issue...)
Save the exit status and make it be the result of the run.
Signed-off-by: Alex Elder <elder@dreamhost.com
Add a script that runs xfstests over a pair of devices that are
specified using command line arguments. The tests are run using
a specified filesystem type (xfs, ext4, or btrfs).
A default set of tests is run if none is specified on the command
line. Normally there's an "auto" group used for this purpose, but
for now I've laid out a (large) subset of them that I know pass on
rbd devices. These can be updated as we find they work reliably.
Signed-off-by: Alex Elder <elder@dreamhost.com>
Attempt to reproduce btrfs bug when rmdirs race with an async snap.
Unsuccessful. Best guess is that we need multiple threads to trigger.
Signed-off-by: Sage Weil <sage@newdream.net>
This was mixed up with min/max_op_len. And max_ops wasn't being used
the initial object creation stage, flooding the OSDs. Or during run().
Signed-off-by: Sage Weil <sage@newdream.net>
Capture Alexandre's script for reproducing #1774 here for posterity, until
we write a properly harnessed test for this. Currently, workunits can't
mount/unmount, and we don't have a way to make ceph-fuse drop it's cache.
Signed-off-by: Sage Weil <sage@newdream.net>
We don't have a great way to guarantee mdsmap updates, but they
should happen on their own and we can loop. Closes#1518.
Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
