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>
Stress btrfs' block group allocation and deallocation while running
fstrim in parallel. Part of the goal is also to get data block groups
deallocated so that new metadata block groups, using the same physical
device space ranges, get allocated while fstrim is running. This caused
several issues ranging from invalid memory accesses, kernel crashes,
metadata or data corruption, free space cache inconsistencies, free
space leaks and memory leaks.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/315 fails messily if the fallocate command isn't present.
generic/299 also uses "fallocate" and "truncate" binaries which may
not be present.
Switch both to use xfs_io, and we already have the _require for
that, because it's what every other test uses...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test verifies that replacing a xattr's value is an atomic
operation. This is motivated by an issue in btrfs where replacing
a xattr's value wasn't an atomic operation, it consisted of
removing the old value and then inserting the new value in a
btree. This made readers (getxattr and listxattrs) not getting
neither the old nor the new value during a short time window.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
NFS doesn't support attr yet, add _require_attrs in generic/277 to
avoid failure when testing on NFS.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
From nfs(5) we can know that atime related mount options have no
effect on NFS mounts, so add _require_atime() helper to skip atime
tests on NFS
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Chandan Rajendra
Namjae Jeon
Filipe Manana
Jaegeuk Kim
Junho Ryu
Dushan Tcholich
Theodore Ts'o
Eryu Guan
Eric Sandeen