This commit changes the script to operate on FS blocks by obtaining the
block size from the underlying filesystem and using it to perform I/O in
units of block sizes.
This commit also uses $SCRATCH_MNT rather than $TEST_DIR for holding the
test files since the FS on $TEST_DIR might be created with a different
block size than the one specified in $MKFS_OPTIONS.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In generic/519, filefrag command use FIBMAP ioctl(-B option) to print
output in extent format(-e option) on purpose and sync file(-s option),
so add _require_filefrag_options() to check if the command supports
all of these options.
References:
1) filefrag supports -e option by commit 2508eaa since e2fsprogs v1.42.7.
2) filefrag supports -B option by commit 5d5e01d since e2fsprogs v1.41.9.
3) filefrag supports -s option by commit e62847c since e2fsprogs v1.41.6.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On ppc64le, block size reported by fstat(2) is 64k (the page size)
i.e. the "preferred I/O size". However src/t_stripealign.c requires the
actual block size of the filesystem. Hence this commit now makes use of
the block size reported by fstatfs(2) syscall.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On upstream kernel, running some tests which corrupt XFS on purpose
got the mismatched output. e.g. running xfs/087:
------------------------------------------------
+ check fs
+ corrupt image
+ mount image
-+ modify files
-broken: 1
+ repair fs
+ mount image (2)
------------------------------------------------
It is reasonable for corrupted XFS to be caught and rejected by mount
or read/write operation.
Fixes: 0828657542 ("xfs: fix blocktrash fuzzers")
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that the file system actually supports preallocation for defrag
tests that end up calling xfs_fsr, as they can't be supported in
always_cow mode.
[Eryu: add comments in code as well]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The always_cow mode can't usefull preallocate space gіven that it
always has to write out of place, and thus will reject falloc or
ioctl calls to preallocate space in a file. Add explicit checks for
preallocation support in various XFS-specific tests to support this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Various reflink tests currently use fallocate to preallocate space
without first checking that preallocations are supported. Add
explicit checks.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test an incremental send operation in a scenario where the relationship
of ancestor-descendant between multiple directories is inversed, and
where multiple directories that were previously ancestors of another
directory now become descendents of multiple directories that used to be
their ancestors in the parent snapshot. This used to trigger an
infinite loop in the kernel code.
This is motivated by a bug found in btrfs which is fixed by the following
patch for the linux kernel:
"Btrfs: send, fix infinite loop due to directory rename dependencies"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Running xfs/205 triggers the following error:
----------------------------------------------
QA output created by 205
+./tests/xfs/205: line 61: 098: value too great for base (error token is "098")
...
----------------------------------------------
If b2 variable is a 2-digit number beginning with 0(e.g. 098),
it will be treated as octal vaule instaed of decimal value. We
try to declare it as decimal value forcely.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There's a bug in the overlayfs implementation starting from the very
first merged version that may cause an Oops of various forms if a
directory is created over a whiteout dentry, but the actual whiteout
on the upper layer was removed to the directory creation.
Reported by: kaixuxia <xiakaixu1987@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In 034.out, the $SCRATCH_MNT is specified by "/mnt/scratch". It's
not flexible. Modify it to fit the different vaule of $SCRATCH_MNT.
Signed-off-by: xiaoli feng <xifeng@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This adds a regression test for a ENOSPC warning which can be
triggered if '-odioread_nolock,nodelalloc' and quota are used.
The bug was fixed by patch
"Ext4: fix ENOSPC when both quota and dioread_nolock are enabled".
[Eryu: add comments on using syncfs instead of sync]
Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure we don't shrink the device past an active swap file, but allow
shrinking otherwise, as well as growing and balance.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure that we don't remove or replace a device with an active swap
file but can add, remove, and replace other devices.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Swap files currently need to exist on exactly one device in exactly one
place.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Btrfs forbids some operations which should not be done on a swap file.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Swap files on Btrfs have some restrictions not applicable to other
filesystems.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We were sorting numerical values with the 'sort' tool without telling it
that we are sorting numbers, giving us unexpected ordering. So just pass
the '-n' option to the 'sort' tool.
Example:
$ echo -e "11\n9\n20" | sort
11
20
9
$ echo -e "11\n9\n20" | sort -n
9
11
20
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfstests doesn't cover FIBMAP test, it cause we brought in a
regression bug fixed by "79b3dbe4adb3 fs: fix iomap_bmap position
calculation".
Although FIBMAP is old, there're still some programs use it, likes
LILO. This case tests if there's physical address overlap returned
by FIBMAP.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The leafn creation test doesn't work on some v4 filesystems
because the field names change. Rearrange the code somewhat so that it
works properly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A bug in file cloning/reflinking was recently found that afftected both
Btrfs and XFS, which was caused by allowing the cloning of an eof block
into the middle of a file when the eof is not aligned to the filesystem's
block size.
The fix consists of returning the errno -EINVAL to user space when the
arguments passed to the system call lead to the scenario of data
corruption. However this overlaps with some cases where the system call,
in Btrfs, returned -EOPNOTSUPP, which means we are trying to reflink
inline extents. That is unsupported in Btrfs due to the huge complexity
of supporting it (due to copying and trimming inline extents, deal with
eventual compression, etc).
We have a few btrfs test cases that verify that attempts to clone inline
extents result in a failure, and are currently expecting an -EINVAL error
message from the output of the cloner program. So create a filter that
converts error messages related to the -EOPNOTSUPP error to messages
related to the -EINVAL error, so that the test can run both on patched
and non-patched linux kernels.
The corresponding btrfs patch for the linux kernel is titled:
"Btrfs: fix data corruption due to cloning of eof block"
And the VFS change that introduces the -EINVAL error return was introduced
by the following linux kernel commit (landed in 4.20-rc1):
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
The btrfs patch is not yet in Linus' tree (it was submitted around the
same time as this change) and the VFS change was introduced in 4.10-rc1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that we can not clone a range from a file A into the middle of a file B
when the range includes the last block of file A and file A's size is not
aligned with the filesystem's block size. Allowing such case would lead to
data corruption since the data between EOF and the end of its block is
undefined.
This is motivated by a bug recently found that affects both Btrfs and XFS
and is fixed by the following commits/patches for the linux kernel:
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
b39989009bdb ("xfs: fix data corruption w/ unaligned reflink ranges")
Btrfs: fix data corruption due to cloning of eof block
The VFS patch landed in kernel 4.20-rc1 and the XFS patch landed in 4.19.
The Btrfs fix is very recent and it is not yet in Linus' tree.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that deduplication of an entire file that has a size that is not
aligned to the filesystem's block size into the middle of a different
file does not corrupt the destination's file data by reflinking the last
(eof) block.
This test is motivated by a bug recently found that affects both Btrfs
and XFS, and is fixed by the following commits/patches for the linux
kernel:
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
dceeb47b0ed6 ("xfs: fix data corruption w/ unaligned dedupe ranges")
de02b9f6bb65 ("Btrfs: fix data corruption when deduplicating between different files")
Btrfs: fix infinite loop on inode eviction after deduplication of eof block
The VFS patch was added to kernel 4.20-rc1 and the XFS and first Btrfs
patches were added to kernel 4.19. The second patch for Btrfs is very
recent and it is not yet in Linus' tree.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test is for a regression that was introduced in kernel v4.17 by
commit 8b58924ad55c ("ovl: lookup in inode cache first when decoding
lower file handle").
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Chandan Rajendra
Xiao Yang
Christoph Hellwig
Filipe Manana
Miklos Szeredi
xiaoli feng
Liu Bo
Xiong Murphy Zhou
Omar Sandoval
Zorro Lang
Darrick J. Wong
Amir Goldstein