When append_reader gets bad data, print the actual and expected values.
This was helpful to me when hunting a failure in generic/069 on ceph
recently.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe noticed that btrfs/220 started failing with some mount option
changes I made recently, but upon closer inspection this test actually
fails in a lot of different ways normally, specifically if you specify
MOUNT_OPTIONS, or if you make an fs with the free space tree.
Address all these issues by reworking how we test that the mount options
are what we expect. First get what the default mount options are for a
plain mount of SCRATCH_DEV. This is used as the baseline, so no matter
how the mount options change in the future it will always work properly.
Secondly instead of specifying a rigid order of the mount options we're
testing, which breaks if we adjust the order in /proc/self/mounts,
simply specify the options we're actually interested in checking. Then
in the test function combine the common options with the new options
we're testing, and then combine that with our actual options and use
some sort magic to see if there's any difference. If there's no
difference then we know we have everything set as expected, if not we
fail.
This patch addresses the initial issue that Filipe noticed, but also
fixes the failures when you specified MOUNT_OPTIONS, or if you made the
fs with the free space tree.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that encryption nonces are unique and random, where randomness is
approximated as "incompressible by the xz program".
This gets indirectly tested by generic/399, but there are some gaps.
It's good to test for this directly too.
This test runs and passes on ext4 and f2fs. It doesn't currently run on
ubifs because _get_encryption_nonce() isn't implemented for ubifs yet.
(At some point I'll probably switch _get_encryption_nonce() to use
FS_IOC_GET_ENCRYPTION_NONCE, which was added in Linux 5.7. But for now
I'd like to keep the tests using it runnable on older kernels too.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/398 contains workarounds to allow for renames of encrypted files
to fail with different error codes. However, these error codes were
fixed up by kernel commits f5e55e777cc9 ("fscrypt: return -EXDEV for
incompatible rename or link into encrypted dir") and 0c1ad5242d4f
("ubifs: switch to fscrypt_prepare_rename()").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/395 contains workarounds to allow for some of the fscrypt ioctls
to fail with different error codes. However, the error codes were all
fixed up and documented years ago:
- FS_IOC_GET_ENCRYPTION_POLICY on ext4 failed with ENOENT instead of
ENODATA on unencrypted files. Fixed by commit db717d8e26c2
("fscrypto: move ioctl processing more fully into common code").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of EEXIST
on encrypted files. Fixed by commit 8488cd96ff88 ("fscrypt: use
EEXIST when file already uses different policy").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of ENOTDIR
on nondirectories. Fixed by commit dffd0cfa06d4 ("fscrypt: use
ENOTDIR when setting encryption policy on nondirectory").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/397 contains workarounds to allow for kernel bugs where trying
to open or create files in an encrypted directory without the encryption
key failed with ENOENT, EACCES, or EPERM instead of the expected ENOKEY.
However, all these bugs have been fixed. ext4 and f2fs were fixed years
ago by commit 54475f531bb8 ("fscrypt: use ENOKEY when file cannot be
created w/o key"). ubifs was fixed by commit b01531db6cec ("fscrypt:
fix race where ->lookup() marks plaintext dentry as ciphertext").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some test cases are missing the 'rm -f $seqres.full' line but are appending
to that file, so everytime they run that file gets bigger and bigger (some
of them are using about a dozen megabytes on one of my test boxes).
So just add the 'rm -f $seqres.full' line to them, together with the comment
that the 'new' script generates for new test cases.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Inline_data is mutually exclusive to DAX inode flag so enabling both
of them is not expected and triggers some errors. It's a regression
test for kernel commit aa2f77920b74 ("ext4: disallow modifying DAX
inode flag if inline_data has been set")
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This runs a set of simple tests where the infile file is the same as the
outfile.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This tests a bug found while testing copy_file_range. This bug was an
issue with how the OSDs handled the truncate_seq value, which was being
copied from the original object into the destination object. This test
ensures the kernel client correctly handles fixed/non-fixed OSDs.
Link: https://tracker.ceph.com/issues/37378
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test remote copy operation (CEPH_OSD_OP_COPY_FROM) with different
combinations of both object sizes and copy sizes.
Test remote copy operation (CEPH_OSD_OP_COPY_FROM) with several
combinations of both object sizes and copy sizes. It also uses several
combinations of copy ranges. For example, copying the 1st object in the
src file into:
1) the beginning (1st object) of dst file,
2) the end (last object) of dst file and
3) the middle of the dst file.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfsprogs 32e11be9 ("xfs_repair: complain about extents in unknown
state") changed the xfs_repair output format as below:
- _("unknown block state, ag %d, block %d\n"),
- i, j);
+ _("unknown block state, ag %d, blocks %u-%u\n"),
+ i, j, j + blen - 1);
It replaces "block" with "blocks". That cause xfs/030 fails. So use
proper regex to filter the 'old' and 'new' output format both.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There was an issue where with filesize > 4G, map.m_lblk
was getting overflow in buff-IO path while converting unwritten to
written extent with dioread_nolock mount option with bs < ps.
Adding a testcase to test for such regressions with dioread_nolock
mount option. To reproduce the same regression w/o the fix
in the kernel, test with bs < ps config.
The following commit fixed the issue in linux.
id1e18b8824dd ("ext4: fix bs < ps issue reported with dioread_nolock
mount opt")
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test several scenarios for RWF_NOWAIT writes, to verify we don't regress
on btrfs specific behaviour (snapshots, cow files, reflinks, holes,
prealloc extent beyond eof).
We had some bugs in the past related to RWF_NOWAIT writes not failing on
btrfs when they should or failing when they shouldn't, these were fixed by
the following kernel commits:
4b1946284dd6 ("btrfs: fix failure of RWF_NOWAIT write into prealloc extent beyond eof")
260a63395f90 ("btrfs: fix RWF_NOWAIT write not failling when we need to cow")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make this test case inline with the kernel patch [1] changes
[1] c6a5d954950c btrfs: fix replace of seed device
So use the sprout device as the replace target instead of the seed device.
This change is compatible with the older kernels.
While at this, this patch also fixes a typo fix as well.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for the issue fixed by the kernel commit
b5ddcffa3777 (btrfs: fix put of uninitialized kobject after seed device
delete).
In this test case, we verify the seed device delete on a sprouted
filesystem.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs does not have options of defining mkfs options via the
environment. Use BTRFS_MKFS_OPTIONS environment variable to set
MKFS_OPTIONS for btrfs.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We have some places that refer to the variable OPTIONS_HAVE_SECTIONS
has OPTIONS_HAVE_SECIONS, obviously a typo. So fix them.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When nfs_export is enabled, the link count of upper dir
objects are more then the expected number in this testcase.
Because extra index entries are linked to upper inodes.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Here won't be "scratch mount failed" messages when mounting SCRATCH_DEV
failed, because _scratch_mount exits early by invoking the following_fail.
_scratch_mount
{
_try_scratch_mount $* || _fail "mount failed"
}
The message is useless and redundant. So drop it.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If one of the subtests of generic/127 fails, we proceed with the
rest of the tests, potentially overwriting useful data. This makes
it stop as soon as any of the subtests fails.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Right now we only track check.log and check.time globally, it would
be nice to do it per-section as well. This makes it easier to parse
results from systems that run a bunch of different configurations at
once.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This new test will test btrfs's qgroup assign functionality. The
test has 3 cases.
- assign, no shared extents
- assign, shared extents
- snapshot -i, shared extents
Each cases create subvolumes and assign qgroup in their own way
and check with the command "btrfs check".
Cc: Qu Wenruo <wqu@suse.com>
Cc: Eryu Guan <guan@eryu.me>
Signed-off-by: Sidong Yang <realwakka@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Jeff Layton
Josef Bacik
Eric Biggers
Filipe Manana
Xiao Yang
Luis Henriques
Zorro Lang
Ritesh Harjani
Anand Jain
Goldwyn Rodrigues
Murphy Zhou
Yang Xu
Matthew Wilcox
Sidong Yang