Btrfs would fail to send if snapshot run concurrently, this test is to make
sure we have fixed the bug.
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 test uses the newly added cloner binary to dispatch full file and
range specific clone (reflink) requests.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check for the btrfsprogs-devel ioctl.h header at configure time. Use it
in src/cloner if present, otherwise fall back to using the copied clone
ioctl definitions.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The cloner program is capable of cloning files using the BTRFS_IOC_CLONE
and BTRFS_IOC_CLONE_RANGE ioctls.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The xfs_db output is different for v5 filesystem metadata, and so
the test fails due to golden image mismatches rather than an actual
test failure. Improve the filter to hide the differences between the
metadata format outputs.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs/299 has failed for me for a long time. In fact, looking at my
logs it has never passed on any of my test machines. IOWs, the
test that was committed was fundamentally broken.
The reason is that it tests project quotas before it tests user or
group quotas and so creates a bunch of files that are owned by root
or privileged users. It think tries to manipulate them as a user,
and, unsurprisingly, it fails to do so. This then causes the test to
throw an error.
The reason it has always failed is the error that is thrown
hardcodes a uid/gid into an error message. This uid/gid is what
causes the golden output mismatch (nobody is 65534 on my machines,
not 99):
*** push past the hard block limit (expect EDQUOT)
[ROOT] 0 0 0 00 [--------] 12 0 0 00 [--------] 0 0 0 00 [--------]
[NAME] =OK= 100 500 00 [--------] 7 4 10 00 [7 days] 0 0 0 00 [--------]
- URK 99: 0 is out of range! [425,500]
+ URK 65534: 0 is out of range! [425,500]
It wasn't until I looked at the xfs/299.full file when trying to
understand why the error was being thrown and whether it shoul dhave
been in the golden output in the first place that I saw the real
problem. That is, All the user/group quota modifications were
failing because of not having permissions to write the files left
behind by the quota test, and that user and group quotas were not
being tested at all by the test.
So, firstly $SCRATCH_MNT needs to be world writeable, and secondly
each test needs to remove the files it created during the test so
they don't impact on furture test iterations.
This then exercises the user and group quotas appropriately, and so
the golden output changes completely to reflect that changes under
user quotas are actually being accounted to the correct user.
Further, the error message that I originally saw errors on goes
away, because everything is now accounted correctly.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Failures were reported in xfs/008 on s390; dchinner suggested that
perhaps the uninitialized "valid" bitmap was behaving differently on
that platform, and sure enough, this patch fixes things up.
TBH, I'm not sure why using an uninitialized bitmap worked at
all, ever, anywhere...?
[ dchinner explains during review:
It depends on glibc behaviour to whether newly allocated memory is
zeroed or not. e.g. for large allocations glibc uses
mmap() to directly map anonymous pages for the allocation. These get
zeroed by the kernel before being mapped into the user address
space. If glibc allocates from the heap and needs to grow it, it
uses sbrk() to grow the heap and those pages are, again, zeroed by
the kernel. However, if the allocation comes from the heap from
previously freed memory, then it doesn't get zeroed.
I'd say that the 3rd case is occurring here - there's memory that is
allocated and freed as part of the program startup that the bitmap
is being allocated from, and so it's not newly zeroed pages that it
is being allocated from... ]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Ever since commit 7e2a19504 ("ls -l reports different file size
depending on platform and user.") xfs/066 has been running stat on
the dump/restore directory instead of the large file that the test
is checking can be dumped and restored correctly. IOWs, it's not
been checking the correct thing for almost 10 years.
This test fails on CRC enabled filesystems because the shortform
directory entry size is different (an extra byte for the filetype
filed), and this is where tracking down the failure has lead me.
Fix this by using the correct target file, and improve it by dumping
an md5sum of the source and target files to ensure they contain the
same data.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test never passed, so the golden output was never properly
verified as correct. Now that the bug is fixed, fix the golden
output to match the actual test output.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The first test may start with the file from the previous test, and
that is in an unknown state. Hence always remove the test file
before the first test so that it doesn't have extents inside the
test range as it is supposed to be testing into a hole.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test 17 of _test_generic_punch uses the filesystem block size to do
a sub-single block punch. The result of this is a files of
different sizes and md5sums when the filesystem block size changes.
However the only difference in file contents if the length of the
file - the zeroed region is always in the same place. Hence we can
use hexdump rather than md5sum to check the output remains
consistent and the hole remains in the correct place despite the
changing block sizes.
Fix up all the golden output for all the tests that use this
function, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs/291 tries to fill the filesystem almost full, so if the log size
changes with mkfs defaults then it's free space calculations are not
longer valid and so it throws lots of ENOSPC errors during a run.
This is not fatal for this test, but it does increase the runtime of
it and fill the 291.full file with unnecessary errors.
The number of frag files it creates is also too many for a 512 byte
inode filesystem (by about 900) so reduce the number of inodes
initially created so the test works ofr 512 byte inodes. With 512
byte inodes, the free space histogram looks like this after the frag
phase:
from to extents blocks pct
1 1 10730 10730 100.00
And for 256 byte inodes:
from to extents blocks pct
1 1 12388 12388 100.00
So these changes do not affect the intended operation of 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>
This test relies of the contents of the sb_features2 field being
known. Make sure ot clear allt eh MKFS_OPTIONS and ensure that we
direct mkfs to create only the simplest of featuresets to test this
functionality.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs incremental send had an issue where it would detect a non-existent
file hole and then overwrite the file section that hole covers with zeroes,
overriding file data that it shouldn't.
The respective btrfs kernel patch that fixed this issue is titled:
Btrfs: fix send file hole detection leading to data corruption
(https://patchwork.kernel.org/patch/3544831/)
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 change adds some new tests for btrfs' incremental send feature.
These are all related with inverting the parent-child relationship
of directories, and cover the cases:
* when the new parent didn't get renamed (just moved)
* when a child file of the former parent gets renamed too
These new cases are fixed by the following btrfs linux kernel patches:
* "Btrfs: more send support for parent/child dir relationship inversion"
* "Btrfs: fix send dealing with file renames and directory moves"
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>
ext4/306 will fail when mounting the ext3 file system it creates if an
ext3-incompatible mount option is applied by _scratch_mount. This can
happen if EXT_MOUNT_OPTIONS is defined appropriately in the test
environment. For example, the block_validity option is commonly used
to enhance ext4 testing, and it is not supported by ext3.
Fix this by instead creating an ext4 file system without extents as a
functionally equivalent substitute. This will also eliminate a
dependency for ext3 support on the test system.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
So this test does lots of fallocate/truncate noise while doing aio
overwrites to try and exercise a deadlock found in ext4. Because it
runs so hard with ENOSPC it can sometimes cause truncate to fail on
btrfs. This is ok and doesn't affect the validity of the test, we
just need to catch the output so it doesn't cause the test to fail.
Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The 'testfile' environment variable is initialized before the
xfstests environment is included into generic/313. TEST_DIR is not
defined at this point and causes the test to operate on the root.
Move the testfile initialization down after the general environment
is sourced.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I noticed while testing a different mkfs option that btrfs/029 was
failing because it was getting the extra output from our mkfs.btrfs.
After I fixed that I was still failing because my version of cp will
spit out the source and destination files, not just the destination
file. So redirect _scratch_mkfs to /dev/null like everybody does
and make the golden output just expect to see "cp failed" instead of
the cp specific output. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Make the test btrfs/025 not depend on the output of the btrfs tools
subvolume, send, receive and filesystem commands output. The output
of these commands has changed several times in the past, and it can
change again in the future. Therefore just test for failure/success
and not for the exact output on the success case.
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>
Btrfs send/scrub/defrag/qgroup need to walk backrefs,this test
is to make sure iterating backrefs with ulist is working and don't
cause a kernel panic here.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs would get a transaction abortion when remounting RW to RO with
flushoncommit enabled. This test is to check if bug still exists.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I forgot to define $seqres in btrfs/026-029. As a result, a file named
.full was created in the current working directory. Fix it.
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>
This testscript creates reflinks to files on different subvolumes,
overwrites the original files and reflinks, and moves reflinked files
between subvolumes.
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Wang Shilong
David Disseldorp
Dave Chinner
Eric Sandeen
Filipe David Borba Manana
Eric Whitney
Josef Bacik
Brian Foster
Koen De Wit