Commit Graph

3883 Commits

Author SHA1 Message Date
Darrick J. Wong 3f59415858 xfs/216: always disable rmap and reflink when creating log size test fs
This test seems to check that log sizes scale up properly with the size
of the filesystem, given a carefully controlled set of mkfs parameters.
Since turning on reflink or rmap will change the minimum log size,
change the test to detect their presence and ensure they're disabled.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-05-10 17:30:09 +08:00
Darrick J. Wong 2fd273886b xfs: refactor minimum log size formatting code
Create a new helper function to discover the minimum log size that will
work with the mkfs options provided, then remove all the hardcoded block
sizes from various xfs tests.  This will be necessary when we turn on
reflink or rmap by default and the minimum log size increases.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-05-10 17:29:57 +08:00
Qu Wenruo 2bb2dd24cc generic: do operations which doesn't take data space on full fs
This test will test if we can still do the following operations when a
full is full:
- buffered write into unpopulated preallocated extent
- clone the untouched preallocated extent
- fsync
- no data loss if power loss happens after above fsync
Above operations should not fail, as they takes no extra data space.

Xfs passes the test, while btrfs fails at fsync and has data loss.
The fix for btrfs is:
"btrfs: Flush before reflinking any extent to prevent NOCOW write falling
 back to CoW without data reservation"

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-05-10 17:21:42 +08:00
Jiufei Xue 80bac2129b generic: check CAP_LINUX_IMMUTABLE capability
It should return error while changing IMMUTABLE_FL and APPEND_FL if the
process has no capability CAP_LINUX_IMMUTABLE.

However, it's not true on overlayfs after kernel version v4.19 since
the process's subjective cred is overridden with ofs->creator_cred
before calling real vfs_ioctl.

The following patch for ovl fix the problem:
  "ovl: check the capability before cred overridden"

Add this testcase to cover this bug.

Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-05-10 16:30:23 +08:00
Xiao Yang 9820d643ea ext4/018: Match the value of File ACL accurately
Since e2fsprogs v1.44.0, debugfs with stat command shows the output:
---------------------------------------------------------------------
debugfs -R 'stat /attrfile' /dev/sda11 2> /dev/null | grep 'File ACL:'
File ACL: 9258
---------------------------------------------------------------------

Before e2fsprogs v1.44.0, debugfs with stat command shows the output:
----------------------------------------------------------------------
debugfs -R 'stat /attrfile' /dev/sda11 2> /dev/null | grep 'File ACL:'
File ACL: 9258    Directory ACL: 0
----------------------------------------------------------------------

"Directory ACL: XXXX" was removed by commit 578fcbf so running ext4/018
with older e2fsprogs(i.e. before v1.44.0) got the following error:
--------------------------------------------------------------------------
+./tests/ext4/018: line 59: 9258    Directory ACL: 0: syntax error in expression (error token is "Directory ACL: 0")
--------------------------------------------------------------------------

we match the value of File ACL accurately to fix it.

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>
2019-05-09 15:34:39 +08:00
Murphy Zhou d349b37c11 generic/532: do not break golden silence if attributes_mask is 0
If the filesystem does not support STATX_ATTR, like NFS, setting
both attributes and attributes_mask to 0 seems the right thing to
do. attributes_mask can be 0 only if attributes is also 0.
This situation is covered by the "&" check in the next line.

Signed-off-by: Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-05-09 15:31:18 +08:00
David Sterba 55f4ad17f3 generic/487: reorder logdev detection after filesystem detection
If SCRATCH_LOGDEV variable is unset, the _require_logdev check fails
earlier than the following check that decides that this test should not
be run on 'btrfs'.

Signed-off-by: David Sterba <dsterba@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-26 11:18:16 +08:00
Darrick J. Wong 26a0e060e4 misc: xfs_fsop_geom_t -> struct xfs_fsop_geom
Remove the typedef usage for the xfs geometry structure, which will
be removed in future patch.

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>
2019-04-26 11:14:25 +08:00
Filipe Manana 195a650883 btrfs: fix filtering of scratch device in test case 048
The recent commit 4529b20e1a ("btrfs/048: amend property validation
cases"), does not properly filter the scratch device because the error
messages are sent to stderr and not to stdout, and the pipe filter only
gets input from the stdout of the btrfs utility. We need to redirect the
stderr of the btrfs utility to its stdout.

Further, the golden output had the path "/mnt/scratch" hardcoded, instead
of using SCRATCH_MNT. Fix that as well.

The test was failing on any setup where the scratch device is not mounted
at "/mnt/scratch".

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-26 11:10:09 +08:00
Filipe Manana 8afebc0223 btrfs: stress send with deduplication and balance running in parallel
Stress send running in parallel with balance and deduplication against
files that belong to the snapshots used by send. The goal is to verify
that these operations running in parallel do not lead to send crashing
(trigger assertion failures and BUG_ONs), or send finding an inconsistent
snapshot that leads to a failure (reported in dmesg/syslog). The test
needs big trees (snapshots) with large differences between the parent and
send snapshots in order to hit such issues with a good probability.

This currently fails on btrfs, hitting a BUG_ON() often, and with btrfs
error messages in dmesg/syslog. The problem has always existed and it is
not new, but probably unnoticed due to lack of test cases that exercise
these btrfs features running in parallel.

The following patches for btrfs fix the problems:

 "Btrfs: fix race between send and deduplication that lead to failures and
  crashes"

 "Btrfs: prevent send failures and crashes due to concurrent relocation"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-25 15:30:58 +08:00
Darrick J. Wong 872050db3c check: filter lockdep bugs when scanning dmesg
Ignore lockdep complaining about its own bugginess when scanning dmesg
output, because we shouldn't be failing filesystem tests on account of
lockdep.

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>
2019-04-21 23:37:19 +08:00
Darrick J. Wong d0e484ac69 check: wipe scratch devices between tests
Wipe the scratch devices in between each test to ensure that tests are
formatting them and not making assumptions about previous contents.

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>
2019-04-21 23:37:19 +08:00
Darrick J. Wong 5bb196119d check: remove require_{test,scratch}* after a test fails
Remove the require_{test,scratch]* sentinel files after a test fails.
This eliminates false fsck corruption reports such as the following:

1. Test A calls _require_scratch, which creates the sentinel file
$RESULT_DIR/require_scratch to facilitate fsck after the test completes.

2. Test A runs some test, which corrupts the scratch filesystem due to
kernel bug or something.

3. Test A calls _fail because of the errors in (2).  Note that the test
case returned 1, so ./check unmounts the test and scratch filesystems
without checking them or removing $RESULT_DIR/require_scratch

4. Test B starts up, but does not call _require_scratch.  The
$RESULT_DIR/require_scratch file is still there.

5. Test B completes successfully.

6. ./check calls _check_filesystems, which sees the
$RESULT_DIR/require_scratch file and runs fsck.

7. fsck reports the corrupt scratch device (which is associated with
test B) even though B did not ever touch the scratch device and it was
actually test A that corrupted the filesystem.

Note that with the "check: wipe scratch devices between tests" patch
applied, we can also reproduce this problem by running xfs/172 and
xfs/195 with a scratch device small enough that the files created in 172
span multiple AGs and therefore cause 172 to fail.

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>
2019-04-21 23:37:19 +08:00
Filipe Manana 18562c4228 btrfs: test send on subvolume with delalloc after setting it to RO mode
Test that if we have a subvolume/snapshot that is writable, has a file
with unflushed delalloc (buffered writes not yet flushed), turn the
subvolume to readonly mode and then use it for send a operation, the send
stream will contain the delalloc data - that is, no data loss happens.

This currently files on btrfs (data loss) but is fixed by a patch for
the linux kernel titled:

  "Btrfs: send, flush dellaloc in order to avoid data loss"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:43 +08:00
Filipe Manana c7d96baf9c fssum: add support for checking xattrs
Currently fssum, mostly used for btrfs test cases that test the btrfs send
feature, ignores completely the existence of xattrs. This change teaches
fssum to find xattrs and make them contribute to the checksum of a
filesystem, so that we can catch filesystem bugs regarding missing, corrupt
or not supposed to exist xattrs (i.e. that an incremental btrfs send does
not forget to create, update or remove xattrs).

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:43 +08:00
Filipe Manana 378722046a fsstress: add operation for listing xattrs from files and directories
The previous patches added support for operations to set, get and delete
xattrs on regular files and directories, this patch just adds an operation
to list the xattrs of a file/directory.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:36 +08:00
Filipe Manana 0babbf1604 fsstress: add operation for deleting xattrs from files and directories
The previous patches added support for operations to set and get xattrs on
regular files and directories, this patch just adds one operation to delete
xattrs on files and directories.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:29 +08:00
Filipe Manana e9ffa8daec fsstress: add operation for reading xattrs from files and directories
The previous patch added support for an operation to set xattrs on regular
files and directories, this patch just adds one operation to read (get)
them.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:22 +08:00
Filipe Manana fc4b0a55b9 fsstress: add operation for setting xattrs on files and directories
Currently fsstress does not exercise creating, reading or deleting xattrs
on files or directories. This change adds support for setting xattrs on
files and directories, using only the xattr user namespace (the other
namespaces are not general purpose and are used for security, capabilities,
ACLs, etc). This adds a counter for each file entry structure that keeps
track of the number of xattrs set for the file entry, and each new xattr
has a name that includes the counter's value (example: "user.x4").
Values for the xattrs have at most 100 bytes, which is more than the
maximum size supported for all major filesystems.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-20 15:34:15 +08:00
Filipe Manana e1a9b1db89 fsstress: allow afsync on directories too
Currently the afsync function can only be performed against regular files.
Allow it to operate on directories too, to increase test coverage and
allow for chances of finding bugs in a filesystem's implementation of
fsync against directories.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-19 15:25:09 +08:00
Filipe Manana 2c492c4d16 fsstress: allow fsync on directories too
Currently the fsync function can only be performed against regular files.
Allow it to operate on directories too, to increase test coverage and
allow for chances of finding bugs in a filesystem's implementation of
fsync against directories.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-19 15:25:01 +08:00
Darrick J. Wong 830349865e clonerange: test remapping the rainbow
Add some more clone range tests that missed various "wacky" combinations
of file state.  Specifically, we test reflinking into and out of rainbow
ranges (a mix of real, unwritten, hole, delalloc, and shared extents),
and also we test that we can correctly handle double-inode locking no
matter what order of inodes or the filesystem's locking rules.

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>
2019-04-14 19:21:52 +08:00
Murphy Zhou 13818987d5 generic/504: fix hard coded fd number
Bash supports file discriptor assignment in this way. So remove the hard
coded numbers. Also close this opened fd in cleanup.

Signed-off-by: Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-14 19:05:36 +08:00
Anand Jain 4529b20e1a btrfs/048: amend property validation cases
Add more property validation cases which are fixed by the patches [1]
 [1]
  btrfs: fix vanished compression property after failed set
  btrfs: fix zstd compression parameter

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-14 10:48:15 +08:00
Brian Foster 2516e6cd4e fsx: test copy_file_range() using non-zero length copy
The copy_file_range() test detection code performs a zero-length
copy to determine whether to perform such calls during the test run.
While this detects the common case of syscall availability,
copy_file_range() has a somewhat variable implementation on the
kernel side that can depend on certain per-filesystem features, etc.
In some implementations, a zero length copy can shortcut and return
success before ever invoking per-filesystem functionality and thus
not thoroughly testing the copy mechanism on the current system.
This can cause the test detection code to pass only to run into an
immediate failure on the first copy_file_range() call during the
test.

Tweak test_copy_range() to perform a small single byte copy to avoid
this problem. Also fix a typo bug in the errno check of the clone
range detection logic.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-04-13 11:01:30 +08:00