The benchmark framework inside xfstests is basically unused,
bitrotted and not very useful. If we need benchmarks, lets use a
real benchmark framework, not xfstests. Kill it to remove
dependencies on common and common.rc.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Phil White <pwhite@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The files used to fill space when using --large-fs contribute
towards the quota of uid 0. Modify the quota output filter in test
050 to "hide" these files from the test output.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The xfsdump/restore tests will see the space filling files and may
try to back them up and restore them, consuming huge amounts of time
to do (especially when diffing the results). Exclude the space
filling files by setting the no dump attributes on them and ensure
that xfsdump runs with the -e flag to exclude such files.
This also needs a dump filter addition to remove the output that
files were skipped, and to decrement the count of files processed by
xfsrestore because the inventory still includes excluded files.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Now that setting up large filesystem testing on sparse loopback
devices uses a generic method for filling the filesystem, extent
support to ext4 filesystems.
ext4 is slightly more complex to fill as it does not support files
larger than 16TB. Hence a slightly more complex method of using
multiple smaller files to fill the space is necessary.
WARNING: be prepared for ext4 to take forever to prepare large
filesystems as allocation of large amounts of space (especially as
it approaches ENOSPC) is can take minutes rather than milliseconds
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Some tests call _check_scratch_device directly and when using a
large filesystem this needs to run with a -t option to avoid
consuming large amounts of memory. Make this happen in all cases
that the scratch device is checked.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Now that large filesystem testing does not play free space games to
fill the space without IO, we can enable xfs_repair when running in
this mode. xfs_repair has had it's scalability problems solved, too,
so this is a safe thing to do.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
To enable sane testing of large scale filesystems, the --large-fs
test option uses xfs_db magic to mark AGs full without doing any IO.
This leaves only a small amount of free space left in the filesystem
to stress the high AGs of the filesystem rather than the low AGs.
This method requires us to have special filesystem check options to
avoid free space checking in xfs_check, and we cannot current run
xfs_repair on such a filesystem at all. As it is, free space
checking on xfs_check does not scale, so we still need to avoid this
checking regardless of how we fill the filesystem.
We can achieve exactly the same fill behavior by preallocating a
single large file in the filesystem immediately after creating it.
This is a filesystem independent manner of filling the filesystem,
and allows us to do large filesystem testing on more than just XFS.
Further, this preallocation method effectively adds a new "very
large file" test. It also enables us to run an unmodified xfs_repair
or filesystem specific fsck program to check the filesystem for
sanity, so we can now do full sanity checking of such large
filesystems.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Rename the $RETAIN_AG_BYTES variable to be more generic so that it
reflects the fact that it is designed to retain a certain amount of
extra free space above the default amount in the filesystem when
doing large scratch device testing.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
USE_BIG_LOOPFS is really misnamed - it can be used on real devices just as
easily as loop devices. It really means we are testing a large scratch device
and that we should enable the special filesystem filling and checking options
that enable xfstests to be run sanely on large XFS filesystems.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
There are many situations where disk may fail for example
1) brutal usb dongle unplug
2) iscsi (or any other netbdev) failure due to network issues
In this situation filesystem which use this blockdevice is
expected to fail(force RO remount, abort, etc) but whole system
should still be operational. In other words:
1) Kernel should not panic
2) Memory should not leak
3) Data integrity operations (sync,fsync,fdatasync, directio) should fail
for affected filesystem
4) It should be possible to umount broken filesystem
Later when disk becomes available again we expect(only for journaled filesystems):
5) It will be possible to mount filesystem w/o explicit fsck (in order to catch
issues like https://patchwork.kernel.org/patch/1983981/)
6) Filesystem should be operational
7) After mount/umount has being done all errors should be fixed so fsck should
not spot any issues.
This test use fault injection (CONFIG_FAULT_INJECTION=y,
CONFIG_FAIL_MAKE_REQUEST=y and CONFIG_FAULT_INJECTION_DEBUG_FS=y config
options) to force all new IO requests to fail for a given device. Xfs
already has XFS_IOC_GOINGDOWN ioctl which provides similar behavior, but it
is fs specific and it does it in an easy way because it performs freeze_bdev()
before actual shutdown.
Test run fsstress in background and then force disk failure.
Once disk failed it check that (1)-(4) is true.
Then makes disk available again and check that (5)-(7) is also true
BE CAREFUL!! test known to cause memory corruption for XFS
see: https://gist.github.com/dmonakhov/4953045
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
1) Add _scale_fsstress_args function which transform arguments according
to load factors
2) Let all non deterministic fsstress tests to use scaled arguments
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
FIO is very flexible io generator, I would call it IO swiss knife.
Currently we have tons of hardcoded application which reproduces
some predefined scenario. This approach has obvious disadvantages
1) Lack of flexibility: one written it is hard to modify it in future
2) Code base is large, many routines written again and again
At the same time add new fio based test, just add simple INI file.
This greatly simplifies code review. I do believe that some day we will
replace most of hardcoded io binaries with fio.
One who is planning to run $FIO_PROG should first check that system
contains appropriate version which is able to handle jobfile
for example: _require_fio 286-job.fio
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
dumpe2fs can be now accessed via $DUMPE2FS_PROG, tests that require it
can check for its availability by _require_dumpe2fs function.
Signed-off-by: Tomas Racek <tracek@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Test 219 requires a special user. Use $qa_user and $qa_group (added in this
patch) for that purpose instead of hardcoded uid & gid. This also fixes
a false failure when repquota does not report quota for users not in passwd.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Without this, 273 was failing in cryptic ways for me
if the device size was < 2G.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Tests the XFS_IOC_ZERO_RANGE ioctl by way of the "xfs_io zero" utility
to ensure it is tossing the expected ranges.
The ranges tested are [0,1] [0,4095] [0,4096] [0,4097] [4095,8191]
[4095,8192] [4095,8193] [4096,8192] [1024,4096]
Signed-off-by: Andrew Dahl <adahl@sgi.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
This reverts commit edd6bcf9c4 which caused
the following tests to fail:
142.out.bad:Can't initialize the DMAPI
143.out.bad:Can't initialize the DMAPI
144.out.bad:Can't initialize the DMAPI
145.out.bad:Can't initialize the DMAPI
146.out.bad:Can't initialize the DMAPI
147.out.bad:Can't initialize the DMAPI
150.out.bad:Can't initialize the DMAPI
155.out.bad:Can't initialize the DMAPI
156.out.bad:Can't initialize the DMAPI
157.out.bad:Can't initialize the DMAPI
158.out.bad:Can't initialize the DMAPI
161.out.bad:Can't initialize the DMAPI
168.out.bad:Can't initialize the DMAPI
175.out.bad:Can't initialize the DMAPI
176.out.bad:Can't initialize the DMAPI
185.out.bad:Can't initialize the DMAPI
This patch might be a little heavy handed, but it seems to
work; if you set USE_QUOTA=1 in your environment, all
tests should be run with quota on and enabled.
This will hopefully help shake out some of the ext4
quota problems, although one needs to keep an eye
on the console to see whether warnings scroll by.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
If an entire device used for file system creation, the mkfs.ext2/3/4
asks for confirmation before proceeding. Since the device is
configured for testing it is safe to assume positive response
during mkfs.
The patch also replaces hard coded mkfs path with MKFS_PROG variable.
Signed-off-by: Chaitanya Kulkarni <chaitanyakulkarni15@gmail.com>
Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Local version of fstrim was dropped so that we depend on upstream
version which is now available via FSTRIM_PROG. _require_fstrim was
added to check if fstrim is available in the system and
_test_batched_discard to check if we can run fstrim on certain
mountpoint.
Also tests 251 and 260 were modified to reflect this change.
Signed-off-by: Tomas Racek <tracek@redhat.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
More filesystems have grown freeze capability, so rather than
hardcoding several in _supported_fs, make tests 068 and 280
generic and then add a new _require_freeze() which checks whether
the fs under test can be frozen before beginning the test.
Minor other cleanups to 280:
- remove extra _supported_fs line
- clear $seq.full before beginning
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
For some reason, non-xfs filesystems weren't getting mounted with
the selinux context; perhaps because none of the xattr tests used
to work on anything but xfs?
Anyway, 062 fails for extN unless we mount with the fs-wide
context.
So export SELINUX_MOUNT_OPTIONS for all filesystems.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We failed to get fsck program to check the btrfs file system, it is
because btrfs uses its independent check tool which is named btrfsck
to check the file system, so the common checker -- fsck -- could not
find it, and reported there is no checker.
This patch fix it by using btrfsck directly.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Dave Chinner
Dmitry Monakhov
Tomas Racek
Jan Kara
Eric Sandeen
Andrew Dahl
Rich Johnston
Prasad Joshi
Eric Sandeen
Miao Xie