This test copies single bytes from a source file into various new
files just to make sure that we can handle very small copies.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test copies data from various points in a source file to a new
file. This is useful for testing the basics of copy_file_range().
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Tests test07, test08, and test09 preallocate a file and assume the
file size used is bigger than 10xbufsz (100xbufsz for test09). This
patch adjusts the file size so this assumption is always true.
As an example, here's test07 output for cephfs, where the allocation
size is set to 4194304, and the output is (4194304 * 10 + 4194304)
07. Test file with unwritten extents, only have dirty pages
07.01 SEEK_HOLE expected 0 or 4194304, got 46137344. FAIL
07.02 SEEK_HOLE expected 1 or 4194304, got 46137344. FAIL
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Bash's 'type -P' builtin is equivalent to 'which', but it's more
efficient because it doesn't involve executing an external binary.
Because set_prog_path() is executed 60+ times in common/config,
which is sourced by common/rc, which in turn is sourced by every
test, switching to 'type -P' actually can make a noticeable
performance improvement for short-running or skipped tests. For
example:
Before:
# time ./check generic/002
...
Passed all 1 tests
real 0m1.365s
user 0m0.746s
sys 0m0.644s
After:
# time ./check generic/002
...
Passed all 1 tests
real 0m1.026s
user 0m0.511s
sys 0m0.470s
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
All callers of set_prog_path() pass it only one argument, the
program to find on the $PATH. Therefore, to simplify things remove
the unused code which allowed fallback paths to be specified in the
remaining arguments.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a test which verifies that dentries in an encrypted directory
are invalidated when an encryption key is added --- which should
cause the plaintext filenames to be visible and accessible,
replacing the encoded ciphertext filenames and any negative dentries
for the plaintext names. This primarily tests for a bug which was
fixed in the v4.5 kernel, plus a v4.6 fix for incorrect RCU usage in
the earlier fix.
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
I didn't end up using this, but somebody else might find
it useful, so sending it.
This change lets us specify punch patterns other than
literally every other block.
i.e. punch-alternating with no options will do:
...HDHDHDHDHDHD...
-i 4 -s 2 will do:
...DDHHDDHHDDHH...
or -i 3 -s 1 will do:
...DDHDDHDDHDDH...
[eguan: don't allow 0 size and fixed perror string]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Block size for cephfs is 4M, which makes generic/020 test fail as the
value for MAX_ATTRS and MAX_ATTRVAL_SIZE will be too high. Restrict these
two variables to sane values for this FSTYP.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: "Yan, Zheng" <ukernel@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
In the v4.11 kernel, the suspicious RCU usage message uses the word
"ERR" rather than "INFO". Update _check_dmesg to accept both
versions.
[eguan: see kernel commit 4d4f88fa235f ("lockdep: Make RCU
suspicious-access splats use pr_err")]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Regression test for kernel commit:
023cc840 xfs: handle array index overrun in xfs_dir2_leaf_readbuf()
See commit for detailed problem description.
tl;dr: readahead on weirdly fragmented multi-block directories
was broken.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Overlayfs directory inodes are constant across copy up,
but not persistent on mount cycle.
Compare the inode numbers before and after mount cycle.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test verifies constant inode number after copy up.
Verify that inode number remains constant also after rename
and drop caches (when overlayfs needs to find the lower
inodes in another location).
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Use helpers to records and check inode numbers so we can repeat
the same test after rename and mount cycle.
Suggested-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Align all comments to the term 'constant inode numbers' and
explain why hardlinks are excluded from this test.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Change test to output golden silence on success.
We are going to run the same check several times,
so instead of cloning the test output, cloning the
silence will be more conveniet.
Generalize cleanup of temp files for the same reason.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs_growfs manpage clearly states that the target path must be an
active xfs mountpoint. This is a test to ensure that if the target
path isn't an active xfs mountpoint, the command is rejected. The
purpose is to check the command response, but not necessarily the
functionality of xfs_growfs. Test cases include absolute paths,
relative paths, symbolic links, and bind mounts.
Signed-off-by: Bill O'Donnell <billodo@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This adds a regression test for the following kernel patch:
dax: fix data corruption due to stale mmap reads
The above patch fixes an issue where users of DAX can suffer data
corruption from stale mmap reads via the following sequence:
- open an mmap over a 2MiB hole
- read from a 2MiB hole, faulting in a 2MiB zero page
- write to the hole with write(3p). The write succeeds but we incorrectly
leave the 2MiB zero page mapping intact.
- via the mmap, read the data that was just written. Since the zero page
mapping is still intact we read back zeroes instead of the new data.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
It's possible for post-eof blocks to end up being used for direct
I/O writes. dio write performs an upfront unwritten extent
allocation, sends the dio and then updates the inode size (if
necessary) on write completion. If a file release occurs while a
file extending dio write is in flight, it is possible to mistake the
post-eof blocks for speculative preallocation and incorrectly
truncate them from the inode. This means that the resulting dio
write completion can discover a hole and allocate new blocks rather
than perform unwritten extent conversion.
A kernel warning can be reproduced by generic/299 on XFS:
XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, \
file: fs/xfs//xfs_trans.c, line: 309
The root cause is that xfs_free_eofblocks() uses i_size to truncate
post-eof blocks from the inode, but async, file extending direct
writes do not update i_size until write completion, long after inode
locks are dropped. Therefore, xfs_free_eofblocks() effectively
truncates the inode to the incorrect size.
Besides reproduce above kernel warning, the verification of written
data is an important distinction between this test and generic/299.
For cover this filesystem corruption testing, write this new case to
check data integrality manually, not only depend on a kernel
warning.
To increase the test stress of aio-dio-eof-race, add two arguments
to this source code to change the file size will be written.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
- Request LIBTOOL to be used
- Set topbuildir based on a Makefile variable to call libtool
- Use /usr/local instead of /var for xfstest final location
- Move macros from aclocal.m4 to acinclude.m4, aclocal.m4 is autogenerated.
- Use autoconf variables @prefix@, @exec_prefix@.
The regular way of compiling xfstests - make - remains.
But it now runs autoreconf and libtoolize -i to produce a valid
configure.
Verified with 'make install --dry-run' that files are installed at the
same place.
Verified compiling in chromeOS chroot works as well.
[eguan: resolve merge conflicts and update .gitignore and remove
generated files by realclean]
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There was a bug during log replay, the attr/attr3 leaf verifier
reported corruption when encountering a leaf attribute with a
count of 0 in the header, as below:
Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
commit f714016 from xfsprogs has fixed this bug. This test case
will emulate this corruption by xfs_db and use xfs_repair to fix
it.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
t_mmap_dio.c actually requires 4 arguments, not 3 as the current
check enforces:
usage: t_mmap_dio <src file> <dest file> <size> <msg>
open src(No such file or directory) len 0 (null)
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Fixes: 456581661b ("xfs: test per-inode DAX flag by IO")
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
We were declaring local arrays using a notation that does not seem to be
standard resulting in failures on some systems, like for example in a
Debian Stretch installation with bash version 4.4.11(1)-release:
$ ./check btrfs/003 btrfs/027
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 4.10.0-rc8-btrfs-next-37+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/003 45s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad)
--- tests/btrfs/003.out 2016-08-23 10:17:35.027012095 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad 2017-04-21 15:53:58.807366940 +0100
@@ -1,2 +1,4 @@
QA output created by 003
-Silence is golden
+./tests/btrfs/003: line 102: devs[]: bad array subscript
+dev balance failed
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/003.full for details)
...
(Run 'diff -u tests/btrfs/003.out /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad' to see the entire diff)
btrfs/027 7s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad)
--- tests/btrfs/027.out 2016-08-23 10:17:35.035012077 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad 2017-04-21 15:53:59.835367271 +0100
@@ -1,2 +1,7 @@
QA output created by 027
Silence is golden
+./common/rc: line 935: devs[]: bad array subscript
+./common/rc: line 893: devs[]: bad array subscript
+mkfs -m raid1 -d raid1 failed
+Bug: str empty, must call _spare_dev_get before its put
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/027.full for details)
...
(Run 'diff -u tests/btrfs/027.out /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad' to see the entire diff)
Ran: btrfs/003 btrfs/027
Failures: btrfs/003 btrfs/027
Failed 2 of 2 tests
So fix this by changing the declaration pattern "local dev[]=..." to the
standard way of "local -a dev=...".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On ext4 filesystem, the kernel carshes at mount time when
s_first_meta_bg's value exceeds the largest possible meta_bg
number. This kernel bug has been fixed in:
3a4b77c ext4: validate s_first_meta_bg at mount time
[eguan: add comments on the first_meta_bg value]
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Anna Schumaker
Luis Henriques
Eric Biggers
Eric Sandeen
Amir Goldstein
Bill O'Donnell
Ross Zwisler
Zorro Lang
Gwendal Grignou
Filipe Manana
Xiao Yang