There are some helpers that invoke setup_root_helper internally so it's
not needed to run test.sh without root, but it should be there in case
the test calls SUDO_HELPER so it's always paired.
Signed-off-by: David Sterba <dsterba@suse.com>
We need to call the setup_root_helper before we start messing with the
loop devices.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We missed a couple of $SUDO_HELPER uses in this test that made it
impossible to run without root. Add them in so we can run as a normal
user.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The setup_root_helper needs to be called before messing with the loop
devices, and btrfs check needs to be run with $SUDO_HELPER.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We need to make sure the root helper is setup before calling the loop
helpers, and additionally we need to use $SUDO_HELPER when we run the
final btrfs check. With this patch we can now run this test as a normal
user.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When 'nullb setup' fails to detect something, e.g. the null_blk module,
the whole test fails though the failure is supposed to be caught and
test not run. Use the correct helper that handles potential failures.
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Test case misc/034 can fail like this:
====== RUN CHECK mount /dev/loop16 /home/adam/btrfs-progs/tests/mnt
mount: /home/adam/btrfs-progs/tests/mnt: wrong fs type, bad option, bad superblock on /dev/loop16, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
failed: mount /dev/loop16 /home/adam/btrfs-progs/tests/mnt
And the dmesg looks like this:
loop16: detected capacity change from 0 to 1024000
loop17: detected capacity change from 0 to 1024000
BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop16 scanned by mount (79348)
BTRFS info (device loop16): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device loop16): found metadata UUID change in progress flag, clearing
BTRFS info (device loop16): disk space caching is enabled
BTRFS error (device loop16): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing
BTRFS error (device loop16): failed to read the system array: -2
BTRFS error (device loop16): open_ctree failed
[CAUSE]
From the dmesg, it shows that although both loopback devices are
properly registered, only one is properly scanned by mount.
Thus the other device is missing, and without "-o degraded" the
filesystem failed to be mounted.
[FIX]
Before we mount the filesystem, also scan them in their passed order
to properly assemble the device list for mount.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
On a 32bit host the split qgroupid is wrong due to the way the numbers
are passed to the formatter as variable length arguments. The level is
u16, promoted to int and then parsed as u64. This means that the values
are shifted and some stack data are printed instead.
Example error messages from yast2-bootloader:
SystemCmd.cc(addLine):569 Adding Line 7 " "qgroupid": "21474836480/23885859321282560","
The value 21474836480 = 0x5000000 is 0x5 shifted by 32 bits,
23885859321282560 is 0x54dc1000000000 and shifting by 32 does not
lead to a valid value which should be 0 in this case.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1209136
Signed-off-by: David Sterba <dsterba@suse.com>
As reported in #588, build fails on some microarchitectures when the
blake2 macros do not coverall combinations. Extend the build tests and
add some uarchs to test.
Signed-off-by: David Sterba <dsterba@suse.com>
Add config for crypto backends (they could fail for the static targets
due to missing static libraries). Reiserfs is not tested and it slowly
disappears from distros.
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Test case cli/017 fails with the following errors:
[TEST] cli-tests.sh
[TEST/cli] 017-fi-show-missing
didn't find exact missing device
test failed for case 017-fi-show-missing
[CAUSE]
After kernel commit cb3e217bdb39 ("btrfs: use btrfs_dev_name() helper to
handle missing devices better"), all dev info ioctl call on missing
device would only return "<missing disk>" for its path.
Thus "btrfs filesystem show" would never report detailed device path for
missing disks.
[FIX]
Instead of relying on the device path, change the check to rely on devid
instead.
Now cli/017 can properly pass.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There are now own copies of ioctl.h and kerncompat.h just for libbtrfs
so the library test should use them.
Signed-off-by: David Sterba <dsterba@suse.com>
The new test case will execute "btrfs subvolume list -u" on the newly
create btrfs.
Since the v0 root item is already deprecated for a long time, newly
created btrfs should be already using the new root item, thus "btrfs
subvolume list -u" should always report the correct uuid.
The test case relies on external program "uuidparse" which should be
provided by util-linux.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add formatter type 'str' where the string must be escaped, e.g. paths or
internal data. Otherwise plain %s can be printed if it's known that
there are no special characters.
Signed-off-by: David Sterba <dsterba@suse.com>
The new test case will make sure btrfs check is fine checking a degraded
raid5 filesystem.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The send stream v2 is supported if the file exists and does not contain
"1". The previous fix reversed the condition but this does not work on
kernel with v1 only support.
Signed-off-by: David Sterba <dsterba@suse.com>
We want to notrun if this test fails, not if it succeeds. Additionally
we want -s, as -q will still print an error if it gets ENOENT from the
file we're trying to grep.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
The test case convert/022 will fail if the system doesn't have
reiserfs support nor reiserfs user space tools:
# make TEST=022\* test-convert
[TEST] convert-tests.sh
WARNING: reiserfs filesystem not listed in /proc/filesystems, some tests might be skipped
[TEST/conv] 022-reiserfs-parent-ref
Failed system wide prerequisities: mkreiserfs
test failed for case 022-reiserfs-parent-ref
make: *** [Makefile:443: test-convert] Error 1
[CAUSE]
Unlike other test cases, convert/022 doesn't even check if we have
kernel support for it.
[FIX]
Add the proper check before doing system wide prerequisities checks.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
After upgrading to kernel v6.0-rc, btrfs-progs selftest mkfs/001 no
longer checks single device RAID0 and other new features introduced in
v5.13:
# make TEST=001\* test-mkfs
[TEST] mkfs-tests.sh
[TEST/mkfs] 001-basic-profiles
$ grep -IR "RAID0\/1" tests/mkfs-tests-results.txt
^^^ No output
[CAUSE]
The existing check_min_kernel_version() is doing an incorrect check.
The old check looks like this:
[ "$unamemajor" -lt "$argmajor" ] || return 1
[ "$unameminor" -lt "$argminor" ] || return 1
return 0
For 6.0-rc kernels, we have the following values for mkfs/001
$unamemajor = 6
$unameminor = 0
$argmajor = 5
$argminor = 12
The first check doesn't exit immediately, as 6 > 5.
Then we check the minor, which is already incorrect.
If our major is larger than target major, we should exit immediate with
0.
[FIX]
Fix the check and add extra comment.
Personally speaking I'm not a fan or short compare and return, thus all
the checks will explicit "if []; then fi" checks.
Now mkfs/001 works as expected:
# make TEST=001\* test-mkfs
[TEST] mkfs-tests.sh
[TEST/mkfs] 001-basic-profiles
$ grep -IR "RAID0\/1" tests/mkfs-tests-results.txt
Data,RAID0/1: 204.75MiB
Metadata,RAID0/1: 204.75MiB
System,RAID0/1: 8.00MiB
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Create a few emulated zoned devices and run mkfs, the zone reset is
expected to be run in parallel. It's using memory-backed devices so it's
too fast to measure the differences and we can't expect availability of
slow zoned devices so this test is very simplistic.
Signed-off-by: David Sterba <dsterba@suse.com>
I've written a simple shell wrapper for null_blk configuration
(https://github.com/kdave/nullb). Make a local copy of version 0.1 to
avoid external dependency for our tests.
Signed-off-by: David Sterba <dsterba@suse.com>
The egrep command is deprecated (per manual page of grep) for a long
time and will probably be removed, the replacement is 'grep -E'.
Signed-off-by: David Sterba <dsterba@suse.com>
Some tests don't use the /tmp temporary files and store it locally in
the test directory. To support NFS this needs to be created by a few
commands. To avoid accidental breakage add a convenience helper.
Signed-off-by: David Sterba <dsterba@suse.com>
To be able to run the test suite on NFS the temporary files need to be
writeable for all, root due to send and owner due to the way it's
created.
Signed-off-by: David Sterba <dsterba@suse.com>
Create a filesystem on a file backed loop block device, then shrink the
file (and its loop block device), then make sure btrfs check can detect
such shrunk device.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The extent leaks are detected in debug builds but tests/scan-build.sh
does not look for them, so add the match expression.
Signed-off-by: David Sterba <dsterba@suse.com>
While testing some changes to how we reclaim block groups I started
hitting failures with my TEST_DEV. This occurred because I had a bug
and failed to properly remove a block groups free space tree entries.
However this wasn't caught in testing when it happened because
btrfs check only checks that the free space cache for the existing block
groups is valid, it doesn't check for free space entries that don't have
a corresponding block group.
Fix this by checking for free space entries that don't have a
corresponding block group. Additionally add a test image to validate
this fix.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The helper `check_min_kernel_version` is duplicated and can be removed.
Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Attempting to dump a bad btrfs superblock returns successful exit status
zero. According to the manual page non-zero should be returned on
failure. Fix this.
$ btrfs inspect-internal dump-super /dev/zero
superblock: bytenr=65536, device=/dev/zero
---------------------------------------------------------
ERROR: bad magic on superblock on /dev/zero at 65536
$ echo $?
0
Signed-off-by: Mike Fleetwood <mike.fleetwood@googlemail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add a test to ensure that 'btrfs fi show' on a mounted filesystem, which
has a missing device will explicitly print which device is missing.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Adapt the existing send/receive tests by passing '-o compress-force' to
the mount commands in a new test. After writing a few files in the
various compression formats, send/receive them with and without
--force-decompress to test both the encoded_write path and the fallback
to decode+write.
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Creating a simple directory structure leads to the following error:
$ btrfs check
Checking filesystem on test.img
UUID: 8f2292ad-c80e-4ab4-8a72-29aa3a83002c
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
unresolved ref dir 260 index 0 namelen 2 name .. filetype 0 errors 3, no dir item, no dir index
ERROR: errors found in fs roots
found 101085184 bytes used, error(s) found
total csum bytes: 98460
total tree bytes: 262144
total fs tree bytes: 49152
total extent tree bytes: 16384
btree space waste bytes: 151864
file data blocks allocated: 167931904
referenced 167931904
The self-reference should exist for the toplevel directory, where the
parent directory points to itself.
Issue: #453
Author: tyan0
Signed-off-by: David Sterba <dsterba@suse.com>
The ext3 has been superseded by ext4, we don't need to test it
separately so this reduces the convert tests run time.
Signed-off-by: David Sterba <dsterba@suse.com>
Add test case is to make sure on a relative large empty fs, we won't
create bitmaps to unnecessarily increase the size of free space tree.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previously 'btrfs check --check-data-csum' will report tons of false
alerts for RAID56.
Add a test case to make sure with the new RAID56 rebuild ability, there
should be no false alerts.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previously we had a bug that btrfs check would report false warning for
a sprouted filesystem.
So this patch will add a new test case to make sure neither seed nor
and sprouted filesystem will cause such false warning.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The new test case will have a image file which has dirty log
(btrfs-image supports dumping log tree).
So we can easily check if "btrfstune -S" will reject fs with dirty log.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The new image has incorrect super num devices (have 8 expect 1).
The image has to be raw format, as btrfs-image restore will reset super
num devices to correct value.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When adding the GC support I noticed we were failing fsck when we had a
directory that hadn't been cleaned up yet because of rm -rf. However
this isn't limited to extent-tree-v2, we'll actually fail in the same
way if we were unable to do the evict portion of the deletion and left
the orphan items around for everybody.
This is a valid file system, it'll be cleaned up properly at mount time,
so fsck shouldn't fail in this case.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
