xfstests: add test for btrfs incremental send data corruption

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>
xfs/199: enforce v4 superblock format for test

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>
xfs/291: fix spurious ENOSPC errors

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>
generic: _test_generic_punch not blocksize clean

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>
generic: inconsistent initial state for test_generic_punch

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>
xfs/296: fix golden output

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>
xfs/066: stat the test file, not the directory

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>
xfs/008: initialize "valid" bitmap in randholes.c

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>
xfs/299: users can't modify root owned files

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>
xfs/021: filter v5 filesystem metadata

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>
btrfs: add small program for clone testing

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>
src/cloner: use btrfs/ioctl.h header if present

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>
btrfs: add new clone overwrite regression test

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>
btrfs: add a regression test for running snapshot and send concurrently

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>
btrfs: add test for data corruption when using compression

Test for a btrfs data corruption when using compressed
files/extents.  Under certain cases, it was possible for reads to
return random data (content from a previously used page) instead of
zeroes. This also caused partial updates to those regions that were
supposed to be filled with zeroes to save random (and invalid) data
into the file extents.

This is fixed by the commit for the linux kernel titled:

   Btrfs: fix data corruption when reading/updating compressed extents
   (https://patchwork.kernel.org/patch/3610391/)

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>
xfs: test setting XFS BMBT fields in xfs_db

Test the setting of the XFS BMBT fields via xfs_db. Runs through the
valid bit values for each field and tests an illegal value.

[dchinner: added _require_xfs_mkfs_crc and turned off crcs so that
the test doesn't just fail on CRC enabled test runs.]

[dchinner: added hex block values to check they don't get endian
swapped.]

Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
btrfs/004: fix to make test really work

So I was wondering why test 004 could pass my previous wrong
kernel patch while it defenitely should not.

By some debugging, i found here perl script is wrong, we did not
filter out anything and this unit test did not work acutally.so
it came out we will never fail this test.

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>
xfs: check that junk in V4 superblocks doesn't break growfs

Test that we properly ignore old growfs-induced junk in the unused
portion of secondary V4 superblocks; at one point this would
trip up the verifiers, and cause a subsequent growfs to fail.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs: ensure bad primary sb crc fails mount

the commit:
10e6e65 xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
broke primary sb CRC validation, not erroring out the mount
if the crc was bad.

This tests that it's fixed, and properly fails the mount on
a bad crc.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
btrfs/005: log test result to right path

We should log test results to $seqres.full not $seq.full.

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>