Refactor xfs/299 to make use of those two crc related pre-checkup
routines, and remove the super block number from the golden output
file as it does not make sense IMO. Also, filter out *EXPERIMENTAL*
string from mkfs.xfs output as those contents would be removed once
crc feature becomes stable.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Generic/314 can fail when the group write file mode bit for "subdir" does not
match that found in the golden output, as has been seen in ext4 regression
testing. It appears that the golden output for generic/314 was taken on a
system where the $qa_user's umask cleared that mode bit - most likely, where
the umask was 022. Depending upon the distro, it's not uncommon for a user's
default umask to have a different value, such as 002. When that's the case,
we get a false negative failure when the group write mode bit for "subdir" is
not cleared. This failure is unrelated to the value of the SGID mode bit
that is the object of this test.
We could either require that $qa_user's account be configured in advance with
a umask of 022, or explicitly set a umask value compatible with the golden
output when creating "subdir". The latter option is more robust.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
generic/240
Date: Wed, 11 Dec 2013 11:21:28 -0000
From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
If we execute generic/240 on a fs which has its fs block size greater
than 64k (for example, NFS), this test will fail with:
io_submit failed: Invalid argument
This will happen because in src/aio-dio-regress/aiodio_sparse2.c this
expression
num_aio = filesize / step;
will set num_aio to 0 and this means that no io_prep_write() will happen
before calling io_submit().
Fixing filesize to be 8 * "fs block size".
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
While running xfstest 280, we occasionally got such error:
setquota: Cannot set quota for user 0 from kernel on
/dev/mapper/xfstests-disk1: No such device
setquota: Cannot write quota for 0 on /dev/mapper/xfstests-disk1: No such
device
setquota calls syscall quotactl, and the kernel will wait for the filesystem
to unfreeze and then performs command. Then kernel will double check if the
device is still mounted. If not, an ENODEV will be thrown.
While in the testcase, unfreeze and umount might be so close that the device
got umounted before quotactl is performed.
Reported-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Signed-off-by: Guangyu Sun <guangyu.sun@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redaht.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Btrfs was screwing up rename+fsync, add some regression tests for
the various scenarios it was screwing up.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs had some issues with fsync()'ing directories and fsync()'ing
after renames. These three new tests cover the 3 different issues
we were seeing. This breaks out the dmflakey stuff into a common
helper to be shared between generic/311 and this new test.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs would crash when the users wrote some data into a file with
compress flag but the compression of the fs was disabled. This test
case is to check this bug still happen or not.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Introduce a new test to verify xfs_quota administrator commands can
deal with invalid XFS mount path properly without NULL pointer
dereference issue.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/273 factors the "space available" output from df into the
calculation for the size of the origin data set. Recent commit
bfdd1e72b3 xfstests: added -P option to $DF_PROG
... converted the use of 'df' to $DF_PROG. This implicitly adds the
-T parameter to add the fs type column, shifts the available space
column over by one and unintentionally causes 273 to look at "used
space" and create too small of a data set for a useful test.
Realign to the available space value.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
A test case to verify if the given raid option for the
metadata and data are actually created.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
We have no tests for testing qgroups, so we have no way of knowing
if our changes are breaking qgroups at all. Get the ball rolling
with some basic functionality tests, these just make sure we can
enable quotas and do rescan and get sane values back, as well as
make sure the limiting stuff works properly.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
For historical reasons beyond my knowledge xfstests tries to abuse the
scratch device as test device for nfs and udf. Because not all test
have inherited the right usage of the _setup_testdir and _cleanup_testdir
helpers this leads to lots of unessecary test failures.
Remove the special casing, which gets nfs down to a minimal number of
failures.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Sugned-off-by: Dave Chinner <david@fromorbit.com>
This test is based on generic/273, a regression test for commit
9a3a5da xfs: check for stale inode before acquiring iflock on push
On unpatched kernel, rm processes would hang.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Various tests opencode checks to find out the minimum support direct I/O
size. Replace those with a generic helper that handles network filesystems as
well. Also remove the Linux 2.4 workaround we had in once place.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The test aims to trigger snapshot-aware defrag path in write endio by
running balance, which is not expected and leads to a crash.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Added -P option to $DF_PROG and changed the invocation of
'df' command in generic/{251,260,273,275} testcases
with $DF_PROG.
Otherwise the testcases will fail if the scratch
device has a long name (for example, if it's an LVM volume).
Because df outputs its usage stats with two lines:
/dev/mapper/xfstests-disk1
3030800 4608 2868908 1% /tmp/mnt/disk1
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Due to partially committed series (fd080d64b6)
generic/273 test uses '_no_of_online_cpus' function which is not defined.
Now it's safe to switch it to 'src/feature -o'.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
xfs/206 displays the output for mkfs.xfs, xfs_growfs and xfs_info.
Change the filtering to hide the new output for the field type
feature.
While cleaning up the ftype output, also clean up the projid32bit
output in xfs_growfs and xfs_info.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
We just want to remove "block device" in _filter_ro_mount(), so add
"mount:" back.
Add one more call of _filter_ro_mount() in xfs/200 to match 200.out.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
On Wed, 30 Oct 2013 09:24:41 -0700
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Oct 30, 2013 at 09:19:55AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 28, 2013 at 11:43:28AM -0400, Dwight Engen wrote:
> > > Hi Cristoph, on my system (where fsgqa is id 501) the one liner
> > > the test is running is:
> > >
> > > # ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
> > > Usage: lstat64 [-t] filename ...
> >
> > The id here is 1000 and the following works just fine:
> >
> > /src/nsexec -s -U -M "0 1000 1000" -G "0 1000 1000" ./src/lstat64
> > Usage: lstat64 [-t] filename ...
>
> But:
>
> ./src/nsexec -s -U -M "0 1000 1000" -G "0 501
> 1000" /root/xfstests/src/lstat64 execvp: Permission denied
>
>
> Which is probably due to:
> root@vm:~/xfstests# ls -ld ~
> drwx------ 6 root root 4096 Oct 30 16:24 /root
>
>
> Guess we need a relative path here?
Yep, that makes sense. I modeled this on 219 which was using
$here/src/lstat64 but didn't think about the fact that in my test fsgqa
might have traversal problems. I see plenty of other tests are using
relative paths so the following patch should (hopefully) fix 317 for you.
Thanks for tracking it down.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
generic/317 and 318 need /proc/<pid>/[uid_map|gid_map], test fail on
older kernels without that support.
Add a _require_ugid_map() function and called by 317 and 318.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
btrfs replace on readonly fs should not be allowed.
Regression test case for commit:
bbb651e Btrfs: don't allow the replace procedure on read only filesystems
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The content of /proc/cpuinfo file is platform-dependent.
So we can not use it reliably to check a number of available cpus.
It would be better to use sysfs interface, as _no_of_online_cpus() does.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Jie Liu
Eric Whitney
Stanislav Kholmanskikh
Guangyu Sun
Josef Bacik
Miao Xie
Brian Foster
Anand Jain
Christoph Hellwig
Eryu Guan
Liu Bo
Mark Tinguely
Dwight Engen
Dave Chinner