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>
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>
Try to punch hole with unaligned size and offset when the FS is
full. Mainly holes are punched at locations which are unaligned
with the file extent boundaries when the FS is full by data.
As the punching holes at unaligned location will involve
truncating blocks instead of just dropping the extents, it shall
involve reserving data and metadata space for delalloc and so data
alloc fails as the FS is full.
btrfs_punch_hole()
btrfs_truncate_block()
btrfs_check_data_free_space() <-- ENOSPC
We don't fail punch hole if the holes are aligned with the file
extent boundaries as it shall involve just dropping the related
extents, without truncating data extent blocks.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
struct xfs_unmount_log_format used to be anonymous and gained a name
in 4.19, so add that to the list of expected structures in xfs/122.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit increases the size of the scsi debug device to 300MiB to
accommodate a 275MiB sized XFS filesystem with 64k block size. mkfs.xfs
fails to create a 64k block sized filesystem on devices with capacity
less than 275MiB.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit replaces the hard coded bsize variable with the block size
obtained from the underlying filesystem.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With 64k block size, 200MiB disk space is not sufficient to create an
XFS filesystem. Hence this commit increases the size of the
overprovisioned dm-thin device to 300MiB. The commit also increases the
other associated disk sizes (original physical size and new physical
size) appropriately.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With 64k blocksized filesystem, this test fails since a single 8k write
will actually end up consuming 64k. Hence this commit writes 64k data
into the test file.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit changes the test to work on file offsets that are aligned
with the block size of the underlying filesystem.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit changes the test to work on file offsets that are aligned
with the block size of the underlying filesystem.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For 64k block size, With 256MiB as the XFS filesystem size and 168 MiB
as the size of the clone source file, we end up hitting ENOSPC when
cloning the source file. This happens due to lack of space for housing
the corresponding metadata. This scenario also occurs when using a
512MiB XFS filesystem and 300MiB clone source file.
Hence this commit increases the size of the test filesystem to 1 GiB and
the size of the clone source file to 768MiB.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With 64k block size, mkfs.xfs fails with the following message when the
filesystem size is 512MiB in size,
"log size 2037 blocks too small, minimum size is 2473 blocks"
Hence this commit increases the test filesystem size to 1GiB. Also, the
size of the test file is increased to 800MiB which is ~80% of the test
filesystem size. This is in proportion to the 400MiB test file used with
the original 512MiB test filesystem.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On a 64k blocksized filesystem, when the test CoWs the file2's offset
range [10 * 64k, 19 * 64k], the call to xfs_bmapi_reserve_delalloc()
allocates 32 64k blocks. This is because XFS_DEFAULT_COWEXTSZ_HINT has
the value of 32 and xfs_get_cowextsz_hint() uses this to compute the
extent alignment. This leads to xfs_bmapi_reserve_delalloc() to reserve
space corresponding to the file range [0, 32 * 64k] in the inode's
cow fork area. On completion of write I/O corresponding to file2's range
[10 * 64k, 19 * 64k], xfs_end_io() moves 10 out of the originally
allocated 32 64k blocks to the data fork area. The remaining 22 64k
blocks linger on in cow fork area of the inode.
Later, when servicing the exit() syscall for the xfs_io process,
xfs_free_eofblocks() ends up invoking xfs_reflink_cancel_cow_blocks()
since i_delayed_blks has the value 22. xfs_reflink_cancel_cow_blocks()
indirectly invokes __xfs_free_extent() which returns EIO since
XFS_ERRTAG_FREE_EXTENT has been set. This leads to the filesystem to be
shutdown. The "rm" command invoked later ends up returning an
error and hence the test fails. The test actually requires that the
filesystem gets shutdown when executing the "rm" command.
To fix the problem, this commit injects the free_extent error after we
CoW file2's [10 * 64k, 19 * 64k] range.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Anand Jain
Filipe Manana
Yufen Yu
Chao Yu
Eric Sandeen
Chandan Rajendra