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>
There was some confused about what the fs was supposed to do when you truncate
at i_size with preallocated space past i_size. We decided on the following
things
1) truncate(i_size) will trim all blocks past i_size.
2) truncate(x) where x > i_size will not trim all blocks past i_size.
This test is to make sure we're all acting sanely. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check if setting the file access and modification times to the current time
and to a specific timestamp is allowed when expected.
In generic/126, remove a left-over temporary file.
Signed-off-by: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test exercises the problem with unwritten and delayed extents
in ext4 extent status tree where we might in some cases lose a block
worth of data. Even though this was a ext4 specific problem the
reproducer can be easily run on any file system so let's do that just
in case.
This test exercises the problem fixed in kernel with commit
"ext4: Fix data corruption caused by unwritten and delayed extents"
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Exercise fs freeze/unfreeze and mount/umount race, which could lead to
use-after-free oops.
This commit fixed the issue:
1494583 fix get_active_super()/umount() race
This test case is based on a script from Monakhov Dmitriy.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Kernel commit
aae8a97 fs: Don't allow to create hardlink for deleted file
disabled hardlink to unlinked file.
Test the race between link and unlink, which could end up adding link
count to an unlinked file and leading to fs corruption on xfs.
Test case was originally written by Eric Sandeen.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Remount ro should not turn qouta off unconditionally, even remount ro
failed, also kernel should not oops on the next succeeded remount ro.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Full DM snapshot devices can return unexpected errors from the
underlying device, and this causes problems for filesystems. In
particular, xfs used to panic in this test, (fixed by commit 8d6c121
"xfs: fix buffer use after free on IO error"), and on current
4.0-rc3 kernels both ext4 and btrfs trigger WARNINGs.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When using mmap() for file i/o, writing to the file should update
it's c/mtime. Specifically if we first mmap-read from a page, then
memap-write to the same page.
This test was failing for the initial submission of DAX because
pfn based mapping do not have an page_mkwrite called for them.
The new Kernel patches that introduce pfn_mkwrite fixes this test.
Test adapted from a script originally written by Dave Chinner.
Signed-off-by: Omer Zilberberg <omzg@plexistor.com>
Signed-off-by: Boaz Harrosh <boaz@plexistor.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test file A fsync after moving one other unrelated file B between
directories and fsyncing B's old parent directory before fsyncing
the file A. Check that after a crash all the file A data we fsynced
is available.
This test is motivated by an issue discovered in btrfs which caused
the file data to be lost (despite fsync returning success to user
space). That btrfs bug is fixed by the following linux kernel patch:
Btrfs: fix data loss in the fast fsync path
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This case tests truncate/collapse range race. If the race occurs, it
will trigger a BUG_ON(). And this kernel patch has fixed this race:
23fffa9 fs: move falloc collapse range check into the filesystem methods
Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
There're six test cases:
- mount at a nonexistent mount point
- mount a free loop device
- mount with a wrong fs type
- umount an symlink to device which is not mounted
- umount a path with too long name
- lazy umount a symlink
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test extent pre-allocation (using fallocate) into a region that already has a
pre-allocated extent that ends beyond the file's size. Verify that if the fs
is unmounted immediately after, the file's size and content are not lost.
This is motivated by a minor issue found in btrfs where the second fallocate
wouldn't update the inode's i_size on disk, fixed by the following btrfs
patch: "Btrfs: add missing inode item update in fallocate()".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
There is no API documentation for RENAME_WHITEOUT. There is no
developer documentation for RENAME_WHITEOUT. There are not comments
in the overlayfs or ext4 implementation of RENAME_WHITEOUT.
Hence, this test simply tries to expose basic RENAME_WHITEOUT
behaviour from ext4 so we can reverse-engineer and verify
bug-for-bug renameat2(RENAME_WHITEOUT) ext4 compatibility.
Note: uses generic/078 just to keep out of the way of the 6-7 other
pending new tests.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@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 the fsync log replay code did not remove xattrs that
were deleted before the inode was fsynced. The result was unexpected
and differed from xfs and ext3/4 for example.
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: remove deleted xattrs on fsync log replay
Signed-off-by: Filipe Manana <fdmanana@suse.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 adding a new hard link to an existing file
(one that was created in a past transaction) and fsync'ing the parent
directory of the new hard link, after the fsync log replay the file's
inode link count did not get its link count incremented, while the new
directory entry was visible.
Also, unlike xfs and ext4, new files under the directory we fsync were
not being written to the fsync log, nor were any child directories and
new files and links under the children directories. So this test verifies
too that btrfs has the same behaviour as xfs and ext4.
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: fix metadata inconsistencies after directory fsync
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eric Sandeen <sandeen@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>
Filipe Manana
Josef Bacik
Andrew Price
Andreas Gruenbacher
Lukas Czerner
Eryu Guan
Omer Zilberberg
Xiaoguang Wang
Dave Chinner
Namjae Jeon