Test that ctime gets updated and suid is cleared when we reflink.
Ensure we can't reflink about RLIMIT_FSIZE. Ensure that we can't
expose stale preallocation block data when reflinking above EOF.
Make sure dedupe actually catches a single different byte.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test was using the "mktemp -d" command to create a temporary
directory for storing send streams and computations from fssum,
without ever deleting them when it finishes. Therefore after running
it for many times it filled up all space from /tmp.
Fix this by using a temporary directory in TEST_DEV instead, as all
the more recent send/receive tests do, to store these files, and
making sure they get deleted when the test finishes. On average the
sum of the size of those files is between 5.5Mb to 6Mb, but changing
the number of operations for fsstress makes it even bigger.
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 if we have a very small file, with a size smaller than the
block size, then fallocate a very small range within the block size
but past the file's current size, fsync the file and then power
fail, after mounting the filesystem all the file data is there and
the file size is correct.
This test is motivated by a failure in btrfs where it triggered an
assertion when using the no-holes feature, that is, when running
with MKFS_OPTIONS="-O no-holes". The btrfs issue is fixed by a patch
for the linux kernel titled:
"Btrfs: fix assertion on fsync of regular file when using no-holes
feature"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Commit 7a7641063a (xfs/140: work with 64k
block size) created a test filesystem with AG size set to (8192 * block
size). When working with a 1k block sized XFS filesystem, this tries to
set the AG size to 8MiB which is less than the minimum AG size of
16MiB. Hence creation of the filesystem had actually failed.
This commit fixes the issue by resetting AG size to 16MiB if (8192 *
block size) results in a value less than 16MiB. Later the test file size
and the test file block count are then appropriately calculated.
Reported-by: Dave Chinner <david@fromorbit.com>
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>
Commit 0e2b99951f (xfs/139: work with 64k
block size) created a test filesystem with AG size set to (8192 * block
size). When working with a 1k block sized XFS filesystem, this tries to
set the AG size to 8MiB which is less than the minimum AG size of
16MiB. Hence creation of the filesystem had actually failed.
This commit fixes the issue by setting AG size to be (16384 * block
size).
Reported-by: Dave Chinner <david@fromorbit.com>
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>
There was a regression in v4.19-rc1 that caused FIGETBSZ ioctl
to return 0 on an overlayfs file.
That regression went unnoticed because the xfstests that run
fiemap-tester program terminated in success status after not doing
much instead of failing.
Check for invalid value of block size returned by FIGETBSZ ioctl,
so these tests can detect the regression.
Fallback to statfs(2) for getting the filesystem blocksize if
FIGETBSZ ioctl fails (i.e. on overlayfs).
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Starting in Linux 4.19 the 'barrier' and 'nobarrier' mount options were
removed. If mount complains about a bad option when we remount with
'barrier', just skip the test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Tests to ensure that the xfs mount code can detect obviously bad fs
summary counters at mount time and fix them.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add Brian Foster's alternate reproducer code for the mread-after-eof
problem so that we increase the chances that either this or generic/499
will catch the problem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If btrfs need to be tested at its default blockgroup which is non-mixed,
then it needs at least 256mb.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we move a file from a directory B to a directory A, replace
directory B with directory A, fsync the file and then power fail, after
mounting the filesystem the file has a single parent, named B and there
is no longer any directory with the name A.
This test is motivated by a bug found in btrfs which is fixed by a patch
for the linux kernel titled:
"Btrfs: fix wrong dentries after fsync of file that got its parent
replaced"
This test passes on ext4, xfs and patched btrfs but it hangs on f2fs (the
fsck.f2fs process seems stuck).
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 if we fsync a tmpfile, without adding a hard link to it, and
then power fail, we will be able to mount the filesystem without
triggering any crashes, warnings or corruptions.
This test is motivated by an issue in btrfs where this scenario triggered
a warning (without any side effects). The following linux kernel patch
fixes the issue in btrfs:
"Btrfs: fix warning when replaying log after fsync of a tmpfile"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Only testing if a domainname is set and ypcat is installed is not a
sufficient criteria to check if NIS is actually active.
Check for a running ypbind in rpcinfo as well.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In case dedupe returns an error in _require_scratch_dedupe(),
report the error for the scratch rather than for the test
filesystem.
Signed-off-by: Anthony Iliopoulos <ailiopoulos@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For the new version of debugfs(v1.44.0+), it changes "File ACL:" format
from "%sFile ACL: %llu Directory ACL: %d\n" to "%sFile ACL: %llu\n".
Thus, update this case accordingly.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
creation time being persisted, so even after sudden power-cut, during
mount, we should recover i_crtime_{,nsec} fields correctly, in order
to not loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
Note that, it needs inode creation time support on specified filesystem.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
i_flags being persisted, so even after sudden power-cut, during
mount, we should recover i_flags fields correctly, in order to not
loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
We only check below attribute modification which most filesystem
supports:
- no atime updates (A)
- secure deletion (s)
- synchronous updates (S)
- undeletable (u)
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
project id being persisted, so even after sudden power-cut, during
mount, we should recover project_id fields correctly, in order to
not loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs needs 256mb to create a fs with default block group which is
non mixed, so pass 256mb to _scratch_mkfs_sized().
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
commit 97575acd74 (generic/015: Change the test filesystem size to
101mb), created 101mb FS instead of 100mb FS to make sure we create
a FS which is non mixed mode.
btrfs-progs commit 18e2663db3e1 (btrfs-progs: Add minimum device
size check) added a more accurate minimum required space to create
the btrfs FS in non mixed mode depending on the group profile, and
considering any group profiles we would need at least 256MB (with
upward round off).
So this patch changes the FS size to be created by
_scratch_sized_mkfs() to 256MB so that we create the FS in non mixed
mode for any group profile.
Mixed blockgroup can be tested using the MKFS_OPTIONS explicitly.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
As of now _scratch_mkfs_sized() checks if the requested size is
below 1G and forces the --mixed option for the mkfs.btrfs. Well the
correct size considering all possible group profiles at which we
need to force the mixed option is roughly 256Mbytes. So fix that.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Filipe Manana
Chandan Rajendra
Amir Goldstein
Anand Jain
Johannes Thumshirn
Anthony Iliopoulos
Yufen Yu
Chao Yu