generic/085 was failing on a machine w/o devicemapper kernel
support because it requires the linear target, but didn't
explicitly test for it.
I could have cut & pasted _require_dm_linear(), but chose
to go the route of a generic helper, _require_dm_target $FOO,
because some day someone will need the zero target, the error
target, or who knows.
Add the helper, use it in test generic/085, and convert
_require_dm_flakey, _require_dm_snapshot, and
_dmerror_required with this new helper.
Reported-by: Angelo Dureghello <angelo.dureghello@nomovok.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
My fault. I didn't set status=0 when removing the filesystem
checking code from Jan's original test code in commit ed2732f
("fstests: Add test of rename").
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Current code always output "truncfile returned 0" because $? was
modified by previous command. Use $ret to indicate the correct
return value from truncfile.
[dchinner: fix formatting issues, update commit message.]
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Calls like fsync() should report failure on partial I/O failure, e.g. a
single failed disk in a raid 0 stripe.
This test is motivated by an XFS bug, and this commit fixed the issue
xfs: return errors from partial I/O failures to files
This case is written by David Jeffery <djeffery@redhat.com> originally.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
For busy-box systems that don't support the extended format options.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test renaming of various entry types in directories of various sizes.
Check that filesystem didn't get corrupted.
[dchinner: fixed missing bits from new test template, removed
checking of scratch as harness does that. ]
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/084 try to run 'tail' command, tail will use inotify.
There're some limit about the number of inotify. For example
fs.inotify.max_user_instances specifies an upper limit on
the number of inotify instances that can be created per real
user ID.
When I test on a machine with 154 cpu cores, this case run
failed, and hit many warning likes:
+tail: inotify cannot be used, reverting to polling: Too many open files
Because the fs.inotify.max_user_instances is 128, so if we
try to tail 154 files, it will be failed.
So use src/multi_open_unlink to instead of tail will avoid
this problem.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Per Dave Chinner's suggestion, modify generic/064 so that it won't fail
if it finds a few more extents than it expects in its test file after
inserting ranges. When 064's test file is first created, some file
systems may use more than the ideal minimum single extent to represent
it, and this can lead to a mismatch between the actual and expected
extent count after the ranges have been inserted. Ext4 file systems
mounted with delayed allocation disabled can exhibit this behavior
if a test file's blocks happen to be allocated across regions of file
system metadata.
Also, replace the open coded counting of extents and holes with a
simpler call to _count_extents(), and clarify some comments.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that when we have a file with multiple hard links belonging to
different parent directories, if we remove one of those links, fsync the
file using one of its other links (that has a parent directory different
from the one we removed a link from), power fail and then replay the
fsync log/journal, the hard link we removed is not available anymore and
all the filesystem metadata is in a consistent state.
This test is motivated by an issue found in btrfs, where the test fails
with:
generic/107 2s ... - output mismatch (see .../results/generic/107.out.bad)
--- tests/generic/107.out 2015-08-04 09:47:46.922131256 +0100
+++ /home/fdmanana/git/hub/xfstests/results//generic/107.out.bad
@@ -1,3 +1,5 @@
QA output created by 107
Entries in testdir:
foo2
+foo3
+rmdir: failed to remove '/home/fdmanana/btrfs-tests/scratch_1/testdir': Directory not empty
...
(Run 'diff -u tests/generic/107.out .../generic/107.out.bad' to see the entire diff)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent (see .../generic/107.full)
_check_dmesg: something found in dmesg (see .../generic/107.dmesg)
$ cat /home/fdmanana/git/hub/xfstests/results//generic/107.full
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
checking extents
checking free space cache
checking fs roots
root 5 inode 257 errors 200, dir isize wrong
unresolved ref dir 257 index 3 namelen 4 name foo3 filetype 1 \
errors 5, no dir item, no inode ref
$ cat /home/fdmanana/git/hub/xfstests/results//generic/107.dmesg
(...)
[188897.707311] BTRFS info (device dm-0): failed to delete reference to \
foo3, inode 258 parent 257
[188897.711345] ------------[ cut here ]------------
[188897.713369] WARNING: CPU: 10 PID: 19452 at fs/btrfs/inode.c:3956 \
__btrfs_unlink_inode+0x182/0x35a [btrfs]()
[188897.717661] BTRFS: Transaction aborted (error -2)
(...)
[188897.747898] Call Trace:
[188897.748519] [<ffffffff8145f077>] dump_stack+0x4f/0x7b
[188897.749602] [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
[188897.750682] [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
[188897.751936] [<ffffffffa04c5d09>] ? __btrfs_unlink_inode+0x182/0x35a [btrfs]
[188897.753485] [<ffffffff8104b410>] warn_slowpath_fmt+0x46/0x48
[188897.754781] [<ffffffffa04c5d09>] __btrfs_unlink_inode+0x182/0x35a [btrfs]
[188897.756295] [<ffffffffa04c6e8f>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
[188897.757692] [<ffffffffa04c6f11>] btrfs_unlink+0x60/0x9b [btrfs]
[188897.758978] [<ffffffff8116fb48>] vfs_unlink+0x9c/0xed
[188897.760151] [<ffffffff81173481>] do_unlinkat+0x12b/0x1fb
[188897.761354] [<ffffffff81253855>] ? lockdep_sys_exit_thunk+0x12/0x14
[188897.762692] [<ffffffff81174056>] SyS_unlinkat+0x29/0x2b
[188897.763741] [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
[188897.764894] ---[ end trace bbfddacb7aaada8c ]---
[188897.765801] BTRFS warning (device dm-0): __btrfs_unlink_inode:3956: \
Aborting unused transaction(No such entry).
Tested against ext3/4, xfs, reiserfs and f2fs too, and all these
filesystems currently pass this test (on a 4.1 linux kernel at least).
The btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix stale dir entries after removing a link and fsync".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Now that generic/038 is running on my test machine, I notice how
slow it is:
generic/038 692s
11-12 minutes for a single test is way too long.
The test is creating
400,000 single block files, which can be easily parallelised and
hence run much faster than the test is currently doing.
Split the file creation up into 4 threads that create 100,000 files
each. 4 is chosen because XFS defaults to 4AGs, ext4 still has decent
speedups at 4 concurrent creates, and other filesystems aren't hurt
by excessive concurrency. The result:
generic/038 237s
on the same machine, which is roughly 3x faster and so it (just)
fast enough to to be considered acceptible.
[Eryu Guan: reduced number of files to minimum needed to reproduce
btrfs problem reliably, added $LOAD_FACTOR scaling for longer
running.]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that if we remove one hard link from an inode, evict the inode,
fsync the inode, power fail and then mount the filesystem, the hard
link we removed does not exists anymore and the filesystem metadata
is in a consistent state.
This test is motivated by an issue found on btrfs, and on an unpatched
btrfs it fails with:
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 4.1.0-rc6-btrfs-next-11+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
generic/098 4s ... - output mismatch (see .../generic/098.out.bad)
--- tests/generic/098.out 2015-07-23 18:01:12.616175932 +0100
+++ .../generic/098.out.bad 2015-07-23 18:04:58.924138308 +0100
@@ -1,3 +1,6 @@
QA output created by 098
Entries in testdir:
+bar
foo
+rm: cannot remove '.../testdir/foo': Stale file handle
+rmdir: failed to remove '.../scratch_1/testdir': Directory not empty
...
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent ...
(...)
$ cat /home/fdmanana/git/hub/xfstests/results/generic/098.full
(...)
checking fs roots
root 5 inode 258 errors 2001, no inode item, link count wrong
unresolved ref dir 257 index 0 namelen 3 name foo filetype 1 errors 6,\
no dir index, no inode ref
unresolved ref dir 257 index 3 namelen 3 name bar filetype 1 errors 5,\
no dir item, no inode ref
(...)
Tested against ext3/4, xfs, f2fs and reiserfs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that if we add hard links (in the same directory) to two files and
then fsync only one of the files, after the fsync log/journal is replayed
all the links exist and the filesystem metadata (directory and file
inodes) is in a consistent state.
This test is motivated by a bug found in btrfs that is fixed by linux
kernel patch titled:
"Btrfs: fix stale directory entries after fsync log replay"
Verified against ext3/4, xfs, f2fs and reiserfs on a 4.1 linux kernel.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS had a regression where inode reclaim in the unlink codepath would
not correctly tear down extended attribute forks where no xattr extents
are present. Add a generic test to create this condition.
The test sets extended attributes on a series of files under ENOSPC
conditions and then verifies that the files can be removed without
syslog warnings or errors.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add a case for testing whether writing failed on NO_SPACE in a busy
loop of write and delete when disk almost full. It is a long-term
problem since very beginning in btrfs, and has been fixed by
patchset titled "btrfs: Fix no_space on dd and rm loop" from
zhaolei@cn.fujitsu.com.
Signed-off-by: Wang Yanfeng <wangyf-fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that if we truncate a file to a smaller size, then truncate it to
its original size or a larger size, then fsyncing it and a power failure
happens, the file will have the range [first_truncate_size, last_size[
with all bytes having a value of 0x00 if we read it the next time the
filesystem is mounted.
This test is motivated by a bug found in btrfs, which is fixed by a patch
titled: "Btrfs: fix fsync after truncate when no_holes feature is enabled"
Tested against ext3/4, xfs, btrfs (with and without the fix, and with the
no_holes feature disabled), f2fs, reiserfs and nilfs2.
All filesystems pass the test except for unpatched btrfs with the
no_holes feature enabled (as expected) and f2fs. Both produce the
following file contents that differ from the golden output:
File foo content after log replay:
0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0200000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
*
0372000
File bar content after log replay:
0000000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
*
0200000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
0372000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0772000
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that after truncating a file into the middle of a hole causes the
new size of the file to be persisted after a clean unmount of the
filesystem (or after the inode is evicted). This is for the case where
all the data following the hole is not yet durably persisted, that is,
that data is only present in the page cache.
This test is motivated by an issue found in btrfs, which got fixed by
the patch titled:
"Btrfs: fix shrinking truncate when the no_holes feature is enabled"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Some tests append logs to $seqres.full and never remove the log, which
keeps the log file growing. Remove $seqres.full before test in
following tests:
ext4/271
generic/019
generic/269
generic/270
shared/272
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Exercise the situation that cause ext4 to BUG_ON() when we use
zero range to zero a range which starts within the isize but ends
past the isize but still in the same block. This particular problem
has only been seen on systems with page_size > block_size.
This tests exercises the problem fixed in kernel with commit
0f2af21aae11972fa924374ddcf52e88347cf5a8
ext4: Allocate entire range in zero range
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test concurrent buffered I/O, DIO, AIO, mmap I/O and splice I/O on the
same files.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I noticed that btrfs wasn't setting unwritten on prealloc test, and then
subsequently noticed that we weren't testing fiemap on prealloc extents with the
fiemap-tester. This patch adds another test that does the same as generic/225
only with prealloc enabled. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by an issue found in btrfs.
It tests that after syncing the filesystem, adding a hard link to a file,
syncing the filesystem again, doing a write to the file that increases
its size and then doing a fsync against that file, durably persists the
data written to the file. That is, after log/journal replay, the data
is available.
The btrfs issue is fixed by the commit titled:
"Btrfs: fix fsync data loss after append write"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
These changes make it possible to run more of the tests on busybox.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Call 'udevadm settle' or 'udevsettle' or 'sleep 1' to make sure new lv
is ready for use before making filesystem on it, depends on which
command is available on the system.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Eric Sandeen
Dave Chinner
Zhao Lei
Eryu Guan
Ari Sundholm
Jan Kara
Zorro Lang
Eric Whitney
Filipe Manana
Dongsheng Yang
Brian Foster
Wang Yanfeng
Lukas Czerner
Josef Bacik