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>
xfs/042 is really an xfs_fsr test, and it only writes about 60MB of
data. however, because it is trying to write lots of data in ENOSPC
conditions, it can take a long time as XFS does flushes to maximise
space usage at ENOSPC. e.g. on a slow 1p VM:
xfs/042 426s ... 425s
It takes a long time to write a small amount of data. To avoid this
slow flushing problem, create the fragmented files with fallocate()
rather than write(), which fails much faster as there is no dirty
data to flush before retrying the allocation and failing. THis
results in:
xfs/042 425s ... 11s
A massive reduction in runtime, such that we can consider putting
xfs/042 into the quick group....
Signed-off-by: Dave Chinner <dchinner@redhat.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>
After upgrading userspace on test machines to xfsprogs-4.2.0-rc1,
lots of build warnings and failures are exposed from implicit
includes that no longer exist. Hence these need fixing to allow
fstests to build correctly.
gcc also seems to have grown new stupidities around uninitialised
variables, so fix them while touching the same files.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an incremental send works after a file gets one of its extents
cloned/deduplicated into lower file offsets.
This is a regression test for the problem fixed by the linux kernel patch
titled:
"Btrfs: teach backref walking about backrefs with underflowed
offset values"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
In _count_extents and _count_holes, the output of 'xfs_io -c "fiemap"'
is saved in var res, but the following "echo $res" will merge the
original output into one line. e.g.
0: [0..63]: 96..159
1: [64..127]: hole
will be
0: [0..63]: 96..159 1: [64..127]: hole
so the extent count is always 0 if there's a hole.
This makes generic/046 fail occasionally. (Seems it's easier to
reproduce when the system is under some presure, e.g. with fsstress
running.)
Tested the new _count_extents and _count_holes with generic/04[3-9] and
tests all passed as expect.
Reported-by: Zorro Lang <zlang@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>
locktest.c has already #included <errno.h>, so remove the unneeded
(and in some cases, incorrect) manual declaration of errno as an
integer. Some C libraries use a macro to provide thread-safety for
errno, so it's incorrect to try to provide a manual declaration.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Instead of the obsolete SysV S_IEXEC, S_IREAD, and S_IWRITE, use
the Posix defines of S_I[WRX]{OTH,GRP,USR}.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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>
Add -d debug dump flag to ./check to directly print a test output
to stdout, instead of just saving it into a file and showing a diff
snippet.
Useful e.g. when writing a new test.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When running ./check and calling a test with a name, id is enough
to find the test (names added in 03c633bf).
If the full test path is tests/xfs/123-foo-bar, then all these
invocations should work, as long as the given part of the test name
is valid and the three-digits id is here.
./check xfs/123-foo-bar
./check xfs/123-foo
./check xfs/123
Always use full test name in results.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This basically does the same as in commit
90a3bfc xfs: be compatible with older mkfs.xfs which has no v5 support
which left xfs/078 behind.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
In manual:
# ./check --help
...
-g group[,group...] include tests from these groups
-x group[,group...] exclude tests from these groups
...
Above format is not supported, because ',' is not parsed in code.
This patch fixed it.
Before patch:
# ./check -g scrub,replace
Group "scrub,replace" is empty or not defined?
After patch:
# ./check -g scrub,replace
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 kerneldev 4.2.0-rc2_HEAD_c65b99f046843d2455aa231747b5a07a999a9f3d_+
MKFS_OPTIONS -- /dev/vdd
MOUNT_OPTIONS -- /dev/vdd /var/ltf/tester/scratch_mnt
...(right result)...
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS had a bug which lead to spurious checksum failures during
verification of log records during recovery. This occurred when the
filesystem was mounted for recovery with a different log buffer size
(via the 'logbsize=...' mount option from when the filesystem crashed.
Create a regression test that dirties the log using one particular log
buffer size, shuts down the fs and attempts recovery using a larger log
buffer size.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Tests xfs_db's ability to change & restore UUIDs on V5 filesystems,
and tests xfs_copy's ability to change the UUID on the copy.
Update to _filter_uuid is so that it will catch the UUID output
from xfs_admin -u, which is slightly different than the regexp it
was expecting.
This requires new userspace which knows how to change the UUID on
a V5 superblock.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@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>
This tests that we can not clone an inline extent into a non-zero file
offset. Inline extents at non-zero offsets is something btrfs is not
prepared for and results in all sorts of corruption and crashes on
future IO operations, such as the following BUG_ON() triggered by the
last write operation done by this test:
[152154.035903] ------------[ cut here ]------------
[152154.036424] kernel BUG at mm/page-writeback.c:2286!
[152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
(...)
[152154.036424] RIP: 0010:[<ffffffff8111a9d5>] [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
(...)
[152154.036424] Call Trace:
[152154.036424] [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
[152154.036424] [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
[152154.036424] [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
[152154.036424] [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
[152154.036424] [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
[152154.036424] [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
[152154.036424] [<ffffffff81165f89>] vfs_write+0xa0/0xe4
[152154.036424] [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
[152154.036424] [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
(...)
[152154.242621] ---[ end trace e3d3376b23a57041 ]---
This issue is addressed by the following linux kernel patch for btrfs:
"Btrfs: fix file corruption after cloning inline extents".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for adding and dropping an equal number of references
for file extents. Verify that if we drop N references for a file extent
and we add too N new references for that same file extent in the same
transaction, running the delayed references (which always happens at
transaction commit time) does not fail.
The regression was introduced in the 4.2-rc1 Linux kernel and fixed by
the patch titled: "Btrfs: fix order by which delayed references are run".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
create_file may run over before growfs, which depends on many reasons. such as
the schedule algorithm, the workload of testing machine, etc. we should always
make sure the create_file run over after growfs, then we can get the valid
result of this test.
Signed-off-by: George Wang <xuw2015@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
On unpatched kernel, converting file with a hole at the beginning to
non-extent based format results in ext4 i_blocks corruption. Add a new
regression test case for it.
These two commits fixed the corruption:
ext4: be more strict when migrating to non-extent based file
ext4: correctly migrate a file with a hole at the beginning
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Eric Whitney
Dave Chinner
Filipe Manana
Eryu Guan
Dave Chinner
Dongsheng Yang
Theodore Ts'o
Kamalesh Babulal
Omar Sandoval
Jan Tulak
Zhao Lei
Brian Foster
Eric Sandeen
George Wang