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>
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>
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>
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>
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>
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>
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>
Koen De Wit
Filipe David Borba Manana
Wang Shilong
Eric Sandeen
Eric Sandeen
Mark Tinguely
David Disseldorp
Dave Chinner