The first test may start with the file from the previous test, and
that is in an unknown state. Hence always remove the test file
before the first test so that it doesn't have extents inside the
test range as it is supposed to be testing into a hole.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test 17 of _test_generic_punch uses the filesystem block size to do
a sub-single block punch. The result of this is a files of
different sizes and md5sums when the filesystem block size changes.
However the only difference in file contents if the length of the
file - the zeroed region is always in the same place. Hence we can
use hexdump rather than md5sum to check the output remains
consistent and the hole remains in the correct place despite the
changing block sizes.
Fix up all the golden output for all the tests that use this
function, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.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>
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>
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>
Introduce a top level common directory and move all the common.*
files into it. Because there is now a directory named common, the
prefix can be dropped from all the files. Convert all the tests to
use this new directory for including common files.
for f in common.*; do \
git mv `echo -n "$f " ; echo $f | sed -e 's;n\.;n/;'` \
done
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Phil White <pwhite@sgi.com>
[rjohnston@sgi.com reworked for TOT changes]
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Dave Chinner
chandan
Zheng Liu
Eric Sandeen
Josef Bacik
Rich Johnston