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 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>
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>
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>
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>
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 test that after syncing the filesystem, adding many xattrs to a file,
syncing the filesystem again, writing to the file and then doing a fsync
against that file, all the xattrs still exists after a power failure.
That is, after the fsync log/journal is replayed, the xattrs still exist
and with the correct values.
The btrfs issue is fixed by the patch titled:
"Btrfs: fix fsync xattr loss in the fast fsync path"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@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>
Dave Chinner
Eryu Guan
Dongsheng Yang
Filipe Manana
Omar Sandoval
Brian Foster
Eric Sandeen
George Wang
Wang Yanfeng
Lukas Czerner
Josef Bacik
Ari Sundholm