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>
When /etc/mtab is linked to /proc/mounts and we are using mount time
created loop devices (i.e. mount -o loop), the unmount can fail
with this amazingly informative error message:
umount: /mnt/scratch/test2: filesystem was unmounted, but mount(8) failed: Invalid argument
What it actually means in this case is that the kernel tore down the
loop device when the last reference went away, and it did it so fast
that mount was not able to find it in /etc/mtab after the unmount
syscall. Hence it could not find the loop device it was supposed to
tear down and has a hissy fit.
This is simple to fix: mount does not need to tear down the loop
device as the kernel does it automatically. Remove the "-d" from
the umount command, and the test passes again.
There's quite a few other tests that also use umount -d - fix them
as well.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The mkfs sector sizes are dependent on the underlying device in use,
and so is not fixed. hence it needs to be filtered from any golden
output file, otherwise tests that just differ by sector size will
fail.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs/104, xfs/119, xfs/291 and xfs/297 have small fixed log sizes. A
recent change to the kernel ramdisk changed it's physical sector
size from 512B to 4kB, and this results in mkfs calculating a log
size larger than the fixed test size and hence the tests fail.
Change the log size to a larger size that works with 4k sectors, and
also increase the size of the filesystem being created so that the
amount of data space in the filesystem does not change and hence
does not perturb the rest of the test.
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>
Several binaries show up in git status after running make in a fresh
clone, and so do files introduced by normal usage.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Reviewed-by: Dave Chinner <dchinner@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>
It's not much fun to run btrfs-specific tests on non-btrfs
filesystems. ;)
> EXT4-fs (dm-12): Unrecognized mount option "inode_cache" or missing value
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@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 commit adds insert operation support for fsstress, which is
meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.
[dchinner: turn off this op for xfs/068, which expects an exact
outcome from the fsstress execution. ]
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@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>
Eryu Guan
Filipe Manana
Zhao Lei
Dave Chinner
Omar Sandoval
Eric Sandeen
Chandan Rajendra
Namjae Jeon
Jaegeuk Kim