The XFS implementation of _scratch_mkfs_sized ignores MKFS_OPTIONS
when a custom block size is set and so isn't testing things like
CRCs on such sized filesytsems. Fix this by ensuring we don't try to
override the block size is it is set in MKFS_OPTIONS. xfs/204 shows
this problem.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The current code incorrectly gets block size information from $TEST_DEV
instead of from $TEST_DIR. This returns the block size of the filesystem
hosting the device file rather than that of the filesystem on $TEST_DEV.
Signed-off-by: chandan <chandan@linux.vnet.ibm.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The btrfs-progs tools changed the output:
- 100GiB instead of 100GB
xfstest btrfs/006 is one that failed due to this change.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test performs btrfs device replace tests with all possible profiles
(single/dup/mixed/raid0/raid1/raid10), one round with the '-r' option
to 'btrfs replace start' and one round without this option. The
cancelation is tested only once and with the dup/single profile for
metadata/data.
This test takes 181 seconds on my SSD equiped test box and 237s on
spinning disks. Almost all the time is spent when the filesystem is
populated with test data. The replace operation itself takes less than
a second for all the tests, except for the test that is marked as
'thorough' which will run for about 8 seconds on my test box.
The amount of tests done depends on the number of devices in the
SCRATCH_DEV_POOL. For full test coverage, at least 5 devices should
be available (e.g. 5 partitions). With less than 2 entries in
SCRATCH_DEV_POOL, the test is not executed.
The source and target devices for the replace operation are arbitrarily
chosen out of SCRATCH_DEV_POOl. Since the target device mustn't be
smaller than the source device, the requirement for this test is that
all devices have _exactly_ the same size. If this is not the case, the
test terminates with _notrun.
To check the filesystems after replacing a device, a scrub run is
performed, a btrfsck run, and finally the filesystem is remounted.
This commit depends on my other commit:
"xfstest: don't remove the two first devices from SCRATCH_DEV_POOL"
[rjohnston: renumbered to btrfs/011]
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
One problem was the output of "uniq -c" which added spaces depending
on the size of the count value (e.g. one space less for 10+ devices).
The second problem was that "btrfs fi show" was doing the same:
"devid %4llu size %s used %s path %s".
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Since common/config is executed twice, if SCRATCH_DEV_POOL is configured
via the environment, the current code removes the first device entry twice
which means that you lose the second device for the test.
The fix is to not remove anything from SCRATCH_DEV_POOL anymore.
That used to be done (I can only guess) to allow to pass the
SCRATCH_DEV_POOL as an argument to _scratch_mkfs. Since _scratch_mkfs adds
the SCRATCH_DEV, the pool mustn't contain that device anymore.
A new function _scratch_pool_mkfs is introduced that does the expected
thing.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This commit adds the possibility to specify RESULT_BASE directory from
the config file, or with environment variable. The default remains the
same "$here/results/".
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Move configuration initialization into a function so we can re-read it
without the need to reinclude the common/config file which would be
ugly. This is in preparation for adding support for sections into config
files.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Move configuration checks into separate function to allow us to recheck
the options without the need to reinclude the whole source file which is
ugly. We still run the check on include.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Currently we do not export some of the important variables in
common/config. Fix this.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
After applied this commit (864688d3), xfstests #255 will not test a
file system that cannot support fallocate(2), such as a indirect-based
file in ext4. So we need to add a new generic test case to test it.
The difference between #255 and this test case is only to use pwrite to
allocate blocks. Other filesystems should survive in this test case.
In the mean time, a new argument '-u' is added into _test_generic_punch
not to run unwritten tests.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
If multiple mount options are given with multiple -o parameters,
_mount_ops_filter concatenates them by replacing all -o's with a comma
(except for the first -o).
If $TEST_DIR contains "-o" (e.g. /mnt/test-os/) you get errors like this:
# ./check generic/002
mount: mount point /mnt/test,s/ does not exist
common/rc: retrying test device mount with external set
mount: mount point /mnt/test,s/ does not exist
common/rc: could not mount /dev/sdc3 on /mnt/test-os/
Fix it by only replacing -o's that are preceded by at least one space.
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston: renumbered test from 003 to 009]
This reverts commit 74bcf51c06.
Unfortunately this commit causes dmapi tests to be run on systems which
don't have dmapi installed, so they fail.
Signed-off-by: Ben Myers <bpm@sgi.com>
I test some of the different mkfs options for btrfs, one set doesn't work
properly with small file systems, so the fs won't mount. This is fine from a
btrfs point of view, but tests that fail to mount the scratch fs will run
anyway, so if it's a "fill the fs" sort of test this will wreak havoc. To fix
this just error out of _scratch_mount fails. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Btrfs has always failed shared/218 because of the way we allocate extents on
disk. The last part of 218 writes contiguously holey from the start of the file
forward, which for btrfs means we get 16 extents but they are physically
contigous. filefrag -v shows all 16 extents, but prints out that there is 1
extent, because they are physically contiguous. This isn't quite right and
makes the test fail. So instead of using filefrag use xfs_io -c fiemap which
will print the whole map and then get the count from there. With this patch
btrfs now passes the test, I also verified that ext4 and xfs still pass this
test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
On distros with older coreutils(eg. RHEL5) generic/294 fails like
-ln: creating symbolic link `SCRATCH_MNT/294.test/testlink': File exists
+ln: creating symbolic link `SCRATCH_MNT/294.test/testlink'File exists
_filter_ln ate the ": ". xfs/103 has similar issue. Add ": " back.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
xfs was having issues with generic/311 because of caching issues. Make
_check_scratch_fs take an optional argument to use as the device to fsck.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Realtime XFS filesystems do not support quotas, so quota tests
always fail on such filesystems. Add a check to _require_quota to
detect this situation and notrun the quota tests...
Also, fix _require_xfs_quota and _require_prjquota to have the same
checks.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
supports seek data/hole operation or not. Here _require_seek_data_hole
is defined to do this work.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The -F flag to xfs_io originally enabled it to operate on non-xfs
filesystems. This restriction was removed upstream in favor of
gracefully failing on the handful of operations that actually
required xfs, and the option was deprecated.
However, xfstests is still used on distros with older xfsprogs, and
so "xfs_io -F" was necessary throughout xfstests.
Simplify this by appending -F to XFS_IO_PROG when it's needed -
i.e. if we're using old xfsprogs on a non-xfs filesystem.
This will eliminate errors when new tests leave out the -F, and
if and when -F is finally removed, there will be one central
location in xfstests to update.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test sets up a dm flakey target and then runs my fsync tester I've been
using to verify btrfs's fsync() is working properly. It will create a dm flakey
device, mount it, run my test, make the flakey device start dropping writes, and
then unmount the fs. Then we mount it back up and make sure the md5sums match
and then run fsck on the device to make sure we got a consistent fs. I used the
output from a run on BTRFS since it's the only one that passes this test
properly. I verified each test manually to make sure they were in fact valid
files. XFS and Ext4 both fail this test in one way or another.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston@sgi.com changed syncfs() to sync() for older kernels]
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test sets up a dm flakey target and then runs my fsync tester I've been
using to verify btrfs's fsync() is working properly. It will create a dm flakey
device, mount it, run my test, make the flakey device start dropping writes, and
then unmount the fs. Then we mount it back up and make sure the md5sums match
and then run fsck on the device to make sure we got a consistent fs. I used the
output from a run on BTRFS since it's the only one that passes this test
properly. I verified each test manually to make sure they were in fact valid
files. XFS and Ext4 both fail this test in one way or another.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston@sgi.com changed syncfs() to sync() for older kernels]
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Dave Chinner
chandan
Stefan Behrens
Dwight Engen
Lukas Czerner
Zheng Liu
Koen De Wit
Josef Bacik
Ben Myers
Eryu Guan
Eric Sandeen
Rich Johnston