This is based on xfs/242. This is very similar to ext4/001 however this
test has some tweaks to make it work test zero range on generic file
system. This includes turning off ext4 extents zeroout and disabling
the test for xfs on systems where PAGE_SIZE > 4096.
It is testing extent tree manipulation with fallocate zero range
operation.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue where the kernel failed
to build paths strings. This resulted either in sending a wrong path string
to the send stream or entering an infinite loop when building it.
This happened in the following scenarios:
1) A directory was made a child of another directory which has a lower inode
number and has a pending move/rename operation or there's some non-direct
ancestor directory with a higher inode number that was renamed/moved too.
This made the incremental send code go into an infinite loop when building
a path string;
2) A directory was made a child of another directory which has a higher inode
number, but the new parent wasn't moved nor renamed. Instead some other
ancestor higher in the hierarchy, with an higher inode number too, was
moved/renamed too. This made the incremental send code go into an infinite
loop when building a path string;
3) An orphan directory is created and at least one of its non-immediate
descendent directories have a pending move/rename operation. This made
an incremental send issue to the send stream an invalid path string that
didn't account for the orphan ancestor directory.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue where invalid paths for
utimes, chown and chmod operations were sent to the send stream, causing
btrfs receive to fail.
If a directory had a move/rename operation delayed, and none of its parent
directories, except for the immediate one, had delayed move/rename operations,
after processing the directory's references, the incremental send code would
issue invalid paths for utimes, chown and chmod operations.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send issuing outdated paths for utimes, chown and chmod
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>
Regression test for btrfs incremental send issue where a rmdir instruction
is sent against an orphan directory inode which is not empty yet, causing
btrfs receive to fail when it attempts to remove the directory.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix send attempting to rmdir non-empty directories
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>
This test was written before a solution was in place, I think,
and so the expected output wasn't well tested.
The test does a loop of sparse writes from 6 to 0, but the
.out file expects 6 (not 7) extents. Fix it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
On old kernel we return EINVAL if hit the limits of maximum number of
ACLs but return E2BIG on new kernel, which cause the test failes on new
kernel as the output is mismatch to the goldens. This patch fix it by
updating the golden output with the new error message and replacing the
old error message with it via a filter.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add missing test for btrfs quota groups feature,test idea is to create
a parent qgroup that groups some subvolume groups, we try to write
some data into every subvolume and then check if we exceed parent
qgroup's limit size.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is based on xfs/242. However it's better to make it file system
specific because the range can be zeroes either directly by writing
zeroes, or converting to unwritten extent, so the actual result might
differ from file system to file system. Also xfs results differ
depending on the page size which is not the case for ext4.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This commit adds fzero operation support for fsstress, which is meant to
exercise fallocate FALLOC_FL_ZERO_RANGE support.
Also reorganise the common fallocate code into a single do_fallocate()
function and use flags use the right mode.
Also in order to make more obvious which fallocate mode fsstress is
testing translate fallocate flags into human readable strings.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
Lukas Czerner
Filipe Manana
Christoph Hellwig
Eric Sandeen
Dmitry Monakhov
Jie Liu
Wang Shilong
Eric Sandeen
ZhangZhen
Dave Chinner