This commit adds insert operation support for fsstress, which is
meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.
[dchinner: turn off this op for xfs/068, which expects an exact
outcome from the fsstress execution. ]
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This testcase tests various corner cases with delayed extents and
pre-existing holes for finsert range functionality over different
types of extents.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This testcase tests various corner cases with pre-existing holes
for finsert range functionality over different type of extents.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This testcase tests various corner cases with delayed extents
for finsert range functionality over different type of extents.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by an fsync issue discovered in btrfs.
The issue was that after punching a hole for a small range, which
affected only a partial page, an fsync operation would have no effect
at all. This was because for this particular case the btrfs hole
punching implementation did not update some btrfs specific inode
metadata that is required to determine if an fsync operation needs
to update the fsync log. For this to happen, it was also necessary
that in the transaction where the hole punching was performed, and
before the fsync operation, no other operation that modified the file
(or its metadata) was performed.
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: add missing inode update when punching hole
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously
fsync'ed successfully, if we end up adding a hard link to our
inode and then persist the fsync log later via an fsync of other
inode for example. This is similar to my previous test, except
that in this test the inode that ends up losing data was created
(with some data) in a transaction different from the one we made
an fsync.
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: fix fsync data loss after adding hard link to inode
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously
fsync'ed successfully, if we end up adding a hard link to our
inode and then persist the fsync log later via an fsync of other
inode for example.
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: fix fsync data loss after adding hard link to inode
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch moves the generic testcases defined in xfs into tests/generic/.
xfs/085 -> generic/052
xfs/086 -> generic/054
xfs/087 -> generic/055
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch adds _get_log_configs for xfs and f2fs to test several
mount options for:
xfs/086
* xfs/087
In xfs/087, one more test was added, so 10 tests will be done in
total.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch removes the mkfs and mount options specified in output
files in xfs/086 and xfs/087.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch defines logstate by adding dump.f2fs for f2fs's clean and
dirty logs. This macro is added into:
xfs/085
xfs/086
xfs/087
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch adds checking code whether filesystem supports norecovery
mount option or not. Use this in the following xfs test.
xfs/200 (recovery vs ro-block device)
Currently, norecovery mount option is used by xfs only. But some of
log-based filesystems (e.g., f2fs) are able to support it later.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
For the follwoing tests, this patch adds general script to get extent and
hole counts.
xfs/137 (data vs filesize)
xfs/138 (data vs filesize vs truncate)
xfs/139 (data vs filesize vs partial truncate)
xfs/140 (data vs filesize vs extending truncate)
xfs/179 (data vs filesize w/ fsync)
xfs/180 (data vs filesize w/ sync)
xfs/182 (data vs filesize w/ recovery)
It also requires these tests to check for fiemap support.
[dchinner: use _require_xfs_io_command "fiemap" for consistency]
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is to detect whether filesystem supports shutdown feature or not.
And let use this into the following xfs tests.
xfs/053 (data exposure)
xfs/137 (data vs filesize)
xfs/138 (data vs filesize vs truncate)
xfs/139 (data vs filesize vs partial truncate)
xfs/140 (data vs filesize vs extending truncate)
xfs/179 (data vs filesize w/ fsync)
xfs/180 (data vs filesize w/ sync)
xfs/182 (data vs filesize w/ recovery)
xfs/200 (recovery vs ro-block device)
xfs/306 (fsstress vs recovery)
xfs/085
xfs/086
xfs/087
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs issue of resizing 'thread_pool' when
remount the fs.
This regression was introduced by the following linux kernel commit:
btrfs: Added btrfs_workqueue_struct implemented ordered
execution based on kernel workqueue
08a9ff3264181986d1d692a4e6fce3669700c9f8
And it was fixed by the following linux kernel commit:
btrfs: fix crash in remount(thread_pool=) case
800ee2247f483b6d05ed47ef3bbc90b56451746c
Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
ext4/304 is also ext4 defragmentation stress test, which creates several
threads to perform defragmentation using 'inplace' mode, but there is a
possible race that the donor file has been truncated by thread_A, while
thread_B starts to call ioctl(EXT4_IOC_MOVE_EXT), then we may get a
EINVAL or ENODATA error.
Please see: http://www.spinics.net/lists/linux-ext4/msg46900.html for
detailed information.
Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Newer versions of btrfs-progs change the default output of 'qgroup
show', we have to check what version is running and use the right option
if needed.
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The secondary superblock verification in xfs_repair was subject to a bug
that unnecessarily leads to a brute force superblock scan if the last
superblock in the fs happens to be corrupt. Normally, xfs_repair handles
one-off superblock corruption gracefully using a heuristic that finds
the most consistent superblock content across the set of secondary
superblocks.
Create a regression test for xfs_repair that corrupts the last
superblock in the fs. Verify the superblock is updated from the
previously verified sb content and a brute force scan is not initiated.
In the event of failure, detect that a brute force scan has started and
abort the repair in order to fail the test quickly.
To support the test, extend the xfs_repair filter to handle corrupted
superblock repair output and provide generic test output for arbitrary
AG counts.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
mkfs executables may live in either /sbin or /usr/sbin, and
the current regexp in this test only catches the former,
and so the test won't run properly with the latter.
Fix this by filtering out whatever was found as
${MKFS_PROG}, rather than a hard-coded /sbin/mkfs path.
Because the list was generated by using a wildcard
with ${MKFS_PROG}.* this will always be the correct filter.
Reported-by: Boaz Harrosh <boaz@plexistor.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Adds a new test that checks for correct behaviour of
XFS_IOC_FSSETXATTR for directories: extent sizes should always be
settable on a directory, even if the directory already has allocated
extents.
Signed-off-by: Iustin Pop <iustin@k1024.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfstests ext4/302, ext4/303 are ext4 defragmentation stress test,
which will ioctl(EXT4_IOC_MOVE_EXT), so EBUSY is expected to happen,
for example, when page's corresponding buffer_head's state is BH_Dirty.
Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Acked-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Namjae Jeon
Filipe Manana
Jaegeuk Kim
Xing Gu
Xiaoguang Wang
David Sterba
Brian Foster
Eric Sandeen
Iustin Pop