mkdir fails due to ENOSPC occasionally and will fail the whole test.
Redirect stdout and stderr to /dev/null.
Also fix the code style in _cleanup to use single tab.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Explicitly fsync the file named 'hello' before checking its content.
This way there's only one expected result for all filesystems.
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>
Many tests use dm_flakey to trigger log replay, but for filesystems that
don't support metadata journaling, this causes failures when it shouldn't.
(i.e. we can hardly test log replay if there is no log, and the subsequent
filesystem check will turn up errors).
For some tests they actually sync everything we care about, and find
inconsistencies elsewhere, but I erred on the side of simply not running
the test in most cases.
Tested-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The test case passes 32K as the offset value to msync. This fails on machines
with 64K page size. Fix this by creating a larger file and passing offset
values which are multiples of 64K.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.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 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 test is motivated by an fsync issue discovered in btrfs.
The steps to trigger the issue were:
1) remove an hard link from an inode with a large number of hard links;
2) add a new hard link;
3) add another hard link with the same name as the one removed in step 1;
4) fsync the inode.
These steps made the btrfs fsync log replay fail (with the -EOVERFLOW
error), making the filesystem unmountable, requiring the use of
btrfs-zero-log (it wipes the fsync log) in order to make the filesystem
mountable again (but losing some data/metadata).
The btrfs issue was fixed by the following linux kernel patches:
Btrfs: fix fsync when extend references are added to an inode
Btrfs: fix fsync log replay for inodes with a mix of regular refs and extrefs
This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).
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 in btrfs was that adding a new hard link to an inode that
already had a large number of hardlinks and fsync the inode, would
make the fsync log replay code update the inode with a wrong link count
(smaller than the correct value). This resulted later in dangling
directory index entries, after removing most of the hard links
(correct_value - wrong_value), that were visible to user space but it
was impossible to delete them or do any other operation on them (since
they pointed to an inode that didn't exist anymore, resulting in -ESTALE
errors).
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: fix fsync when extend references are added to an inode
This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).
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 after fsyncing an inode that got its link count
decremented, and the new link count is greater than zero, after the
fsync log replay the inode's parent directory metadata became
inconsistent - it had a wrong i_size and dangling index entries which
prevented the directory from ever being removed (rmdir always failed
with -ENOTEMPTY, even if the directory had no more child inodes).
The btrfs issue was fixed by the following linux kernel patch:
Btrfs: fix directory inconsistency after fsync log replay
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Some filesystems do not support O_DIRECT. Check whether TEST_DIR supports
it by running xfs_io with -d flag.
Signed-off-by: Junho Ryu <jayr@google.com>
Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
To check for FITRIM tests used _require_fstrim() and
_test_batched_discard() but as _test_batched_discard() already
includes _test_fstrim() unify FSTRIM check throughout xfstests with
_require_batched_discard().
Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
These tests use the falloc command in xfs_io, and there are some file
systems (ext3) or file system configurations (ext4 in ext3
compatibility mode) which do not support fallocate. So add the
explicit requirement to avoid false test failures.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Fix two problems in generic/299
1. Remove $seqres.full before test, otherwise the file is growing all
the time.
2. Make sure fio really exits, otherwise fio would block umount. $pid is
the pid of function run_check not fio, sometimes fio is still there when
$pid is dead and blocking umount.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Eryu Guan
Filipe Manana
Dave Chinner
Eric Sandeen
Chandan Rajendra
Namjae Jeon
Jaegeuk Kim
Junho Ryu
Dushan Tcholich
Theodore Ts'o