Move the inclusion of falloc.h with all it's possible defines for the
fallocate mode into global.h header file so we do not have to include
and define it manually in every tool using fallocate.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test for fallocate zero range at block boundary. This is similar to
the test xfs/290 however this one is generic and we're testing different
block sizes as well - namely 1k, 2k, 4k and 64k. Note that we're not
creating file systems with given block size buy rather test all 4
options.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Create new function _test_block_boundaries() which is testing content of
the blocks after the operation such as zero, or punch hole. The test is
doing the operation around block boundaries to assure correct behaviour
of the operation on block unaligned ranges.
This has been based on test xfs/290 which has been changed to use this
new function. A small change to the output file was required.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Currently there are several function testing various xfs_io commands.
This commit creates _require_xfs_io_command() to test any xfs_command.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
io_getevents returns the number of events; printing its
return as "bytes read" is ... wrong.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is a regression test to verify that the restore feature of btrfs-progs
is able to correctly recover files that have compressed extents, specially when
the respective file extent items have a non-zero data offset field.
This issue is fixed by the following btrfs-progs patch:
Btrfs-progs: fix restore dealing with compressed extents
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
- It would be useful to have verifiable logging mode which will contain
only deterministic information which allow to compare two logs files
generated from two runs with same seed.
- Also add missed help for '-o logfile' option
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
As recently suggested by Dave Chinner, make use of the new function
named _run_btrfs_util_prog() to run the btrfs util program.
Filipe David Borba Manana have cleaned up btrfs/030 and btrfs/034.
I have done the same for the rest ones.
Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
To avoid repeating detection of fssum presence in many btrfs tests, as
suggested by Dave Chinner.
Also exported the variable "here" from the main control script, to avoid
repeating its declaration in every single testcase file. Also removed the
declaration of "here" from btrfs test cases that require the fssum program
only. Removing it from all other test cases will be a separate change.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When running on a ramdisk, the fsstress background workload consumes
a GB of disk space every 5 seconds. This leads to the test failing
with ENOSPC because the test file cannot be created due otthe
background load cosuming it all. Hence don't run this test unless
the scratch device is large enough not to hit ENOSPC conditions.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I'm running xfstests against a ramdisk, so I'm limited in size of
the test and scratch devices. While there are large enough to hold a
filesystem image with a 2GB log, the way the log changes position in
an image file as the size of the filesystem increases means that the
aggregated disk space of xfs/217 is more than enough to run a 4GB
TEST_DEV out of space and hence fail the test.
To avoid this problem, punch out the image file between every mkfs
iteration so that it only consumes the space needed by each
individual mkfs tests, not an aggregation of them all.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
On a fast device like a ramdisk, kernel time may not have changed
between a stat of a file and some operation on it immediately
afterwards. Hence there is no guarantee that an operation actually
changes the timestamps of a file immediately after it is stat'd.
Hence, ensure that the times will change by sleeping for a second
between the initial stat that reads the timestamps and the
operations that is supposed to modify them. This way we ensure that
the timestamp will change if the filesystem is correctly
implemented.
While there, fix the indenting to be 8 space tabs and correct the
header which is missing the bash shell declaration and the test
number identifier.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Version 5 filesystems always have attr2 format enabled, and it
cannot be turned off via the noattr2 mount option. As such, attempts
to mount with noattr2 will be rejected and this causes cascading
failures within the test.
Hence detect if we've created a CRC enabled filesystem, and if this
is the case _notrun the test.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
CRC enabled filesystems emit different errors on corruption.
Specifically, inode corruption is picked up much earlier due to
verifier failures (e.g. incorrect inode identifier) and so
xfs_repair throws errors sufficiently different that filtering
cannot hide the differences. Hence simply add a new golden output
file and link it appropriately once we know what type of filesystem
we are testing.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
We execute collapse range multiple times on same file. Each
collapse range call collapses a single alternate block. After the
test execution, file will be left with 80 blocks and as much number
of extents. We also check for file system consistency after the
completion.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
shared/004 tries to test various corner cases with delayed extents
and pre-existing holes for fcollapse range functionality over
different type of extents.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
shared/003 tries to test various corner cases with pre-existing holes
for fcollapse range functionality over different type of extents.
Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
shared/002 tries to test various corner cases with delayed extents
for fcollapse range functionality over different type of extents.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Tests the noatime, relatime, strictatime and nodiratime mount
options.
There is an extra check for Btrfs to ensure that the access time is
never updated on read-only subvolumes. (Regression test for bug
fixed with commit 93fd63c2f001ca6797c6b15b696a484b165b4800)
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
As recently suggested by Dave Chinner, make use of the new function
named _run_btrfs_util_prog() to run the btrfs util program, and stop
using run_check for running xfs_io - instead filter xfs_io's output
and add it to the golden output.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs incremental send issue where an rmdir
instruction was sent multiple times for the same target directory.
The number of times depended on the number of hardlinks against
the same inode inside the target directory. That inode must have
had the highest number of all the inodes that were children of the
directory. This made the btrfs receive command fail immediately once
it received the second rmdir instruction.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, don't send rmdir for same target multiple times
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue related to
renaming of directories. If at the time of the initial send we have
a directory that is a child of a directory with a higher inode
number, and then later after the initial full send we rename both
the child and parent directories, but without moving any of them, a
subsequent incremental send would produce a rename instruction for
the child directory that pointed to an invalid path. This made the
btrfs receive operation fail.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: incremental send, fix invalid path after dir rename
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test for a btrfs incremental send issue where we end up sending a
wrong section of data from a file extent if the corresponding file
extent is compressed and the respective file extent item has a non
zero data offset.
Fixed by the following linux kernel btrfs patch:
Btrfs: use right clone root offset for compressed extents
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Lukas Czerner
Eric Sandeen
Filipe David Borba Manana
Dmitry Monakhov
ZhangZhen
Dave Chinner
Namjae Jeon
Koen De Wit
Wang Shilong