Create subvolumes and delete every N-th to generate output where we can
also see how the stale qgroups are placed (at the end).
Issue: #687
Signed-off-by: David Sterba <dsterba@suse.com>
The kernel patch, ("btrfs: reject device with CHANGING_FSID_V2 flag"),
removes kernel support for the CHANGING_FSID_V2 flag. So, drop its
related testcase.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The misc-test/034-metadata_uuid test case, has four sets of disk images
to simulate failed writes during btrfstune -m|M operations. As of now,
this tests kernel only. Update the test case to verify btrfstune -m|M's
functionality to recover from the same scenarios.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add appropriate prefix to the error messages to make it easier to track
down which case failed.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Previous commit "btrfs-progs: dump-super: print actual metadata_uuid
value" changed the value of the super_block::metadata_uuid to be printed
as it is, without tweaking it depending on the METADATA_UUID flag.
Apply similar tweak in the common helper functions used to read the
metadata_uuid so that test-cases still be successful.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Test case misc/046-seed-multi-mount would always fail with the following
error:
[TEST] misc-tests.sh
[TEST/misc] 046-seed-multi-mount
unexpected success: writable file despite read-only mount
test failed for case 046-seed-multi-mount
[CAUSE]
Although mounting seed device is indeed read-only, sprouting it with a
new device would always make it read-write by itself.
The behavior is already there for a long time, thus expecting a new
behavior (not changing the read-only flag) is a little weird.
[FIX]
Instead of doing the write check after the sprout, do it before the
sprout.
This looks more correct, and would not rely on the kernel behavior
change (if we determine to go that path).
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
When I was testing misc/058, the fs still has around 7GiB free space,
but during that test case, btrfs kernel module reports write failures
and even git commands failed inside that fs.
And obviously the test case failed.
[CAUSE]
It turns out that, the test case itself would require 6GiB (4 data
disks) + 1.5GiB x 2 (the two replace target), thus it requires 9 GiB
free space.
And obviously my partition is not that large and failed.
[FIX]
In fact, we really don't need that much space at all.
The test verifies that two consecutive replace operations can be started
and enqueued, the sleep of 1 second is not strictly necessary as the
first command should start the replace right away.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[PROBLEM]
Since we have migrated to default v2 cache, the test case
misc/030-missing-device-image is no longer executed:
[TEST/misc] 030-missing-device-image
[NOTRUN] unable to create v1 space cache
[CAUSE]
The test case itself is trying its best to cover all paths, including
the data extent read path.
Thus the test case is requiring v1 cache, as that's the only way to
cover the data read path.
[FIX]
Just remove the v1 space cache requirement, it's still better to run the
test even it only exercises the metadata read path.
The good news is, after commit 3ff9d35257 ("btrfs-progs: use
read_data_from_disk() to replace read_extent_from_disk() and replace
read_extent_data()"), all data/metadata read paths are unified.
They only difference is the verification part.
Thus even if we didn't fully exercise the data read path, we didn't lose
much coverage anyway.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The test misc/058 does not properly filter out the output due to -s that
only ignores non-existent files and was there due to previous changes.
We need to use -q.
Signed-off-by: David Sterba <dsterba@suse.com>
Fix failures caused by the lack of ACL support in btrfs. For example:
$ make test
::
[TEST/misc] 057-btrfstune-free-space-tree
failed: setfacl -m u:root:x /Volumes/ws/btrfs-progs/tests/mnt/acls/acls.1
test failed for case 057-btrfstune-free-space-tree
make: *** [Makefile:493: test-misc] Error 1
Similar failures occurred in the test cases convert/001-ext2-basic,
convert/003-ext4-basic, convert/005-delete-all-rollback, and
convert/006-large-hole-extent.
Resolve it by adding a check for ACL support using the
check_kernel_support_acl() helper function. It gracefully handles the case
when ACL support is not compiled by calling _not_run().
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The new test case would create a fs without free space tree, then
populate it, convert to free-space-tree feature, and make sure
everything is fine.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Executing the script inside the directories as './test.sh' is not
supposed to work but could happen accidentally. With an exit after
attempting to source the we can fix that.
Signed-off-by: David Sterba <dsterba@suse.com>
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>
[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>
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>
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>
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>
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>
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>
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>
There's a report that a read-only subvolume with a received_uuid set
emits the warning in command 'btrfs subvolume show', which is obviously
wrong.
The reason is that there are different types of root item flags,
depending on how we read them. The check in cmd_subvol_show uses the
ioctl GET_SUBVOL_INFO and the appropriate flag is raw
BTRFS_ROOT_SUBVOL_RDONLY (0x1), while there's another SUBVOL_GETFLAGS that
maps the flags and the raw value is different (BTRFS_SUBVOL_RDONLY, 0x2).
Due to this the warning was issued. Fix that by using the right flag
constant. The test has been extended to check for all combinations of
read-write and received_uuid.
Issue: #419
Signed-off-by: David Sterba <dsterba@suse.com>
Use the helpers to create temporary files, this save some typing and
we'll have a bit more consistent naming.
Signed-off-by: David Sterba <dsterba@suse.com>
The file names are build from roughly these components:
- btrfs-progs as prefix
- category (mkfs, convert) or what's the type of the file like 'image'
- the substitution template, XXXXXX
Signed-off-by: David Sterba <dsterba@suse.com>
Test case misc/038 uses hard coded backup slot number, this means if we
change how many transactions we commit during mkfs, it will immediately
break the tests.
Such hard coded tests will be a big pain for later btrfs-progs updates.
Update it with runtime backup slot search.
Such search is done by using current filesystem generation as a search
target and grab the slot number.
By this, no matter how many transactions we commit during mkfs, the test
case should be able to handle it.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add a slightly more convenient way to identify the subvolumes with bad
combination of flags and received uuid.
Signed-off-by: David Sterba <dsterba@suse.com>
The test misc-tests/038-backup-root-corruption expects a particular
layout of the backup roots but this gets slightly changed due to free
space tree.
$ make TEST=038-backup-root-corruption TEST_ARGS_MKFS='-Rfree-space-tree' TEST_ENABLE_OVERRIDE=true test-misc
Will result in test failure as the expected root is in slot 3 and not 2.
Update the test to try both.
Signed-off-by: David Sterba <dsterba@suse.com>
Although btrfstune will already warn users to make sure the fs is not
corrupted, we can never trust end users.
If the target fs has transid error, btrfstune can cause further damage,
thus we need to make sure btrfstune can safely reject fs with transid
error, other than ignoring the problem.
The image is copied from fsck-tests/002, just override check_image() to
run "btrfstune -u" instead.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This new test case is to make sure the restored image file has been
properly enlarged so that newer kernel won't complain.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The warning is printed for profiles where it's not intended (like raid0
or raid1c4). Check the correct variable for the target profiles.
Issue: #355
Fixes: 1ed5db8db4 ("btrfs-progs: balance convert: add a warning and countdown for RAID56 conversion")
Signed-off-by: David Sterba <dsterba@suse.com>
When running the tests as root SUDO_HELPER is empty, so that
`run_check "" dd ...` is run, and it fails because the empty command is
not found.
Pull-request: #351
Issue: #352
Author: Pierre Labastie <pierre.labastie@neuf.fr>
Signed-off-by: David Sterba <dsterba@suse.com>
The current mount detection code in btrfs receive is not quite perfect.
For example, suppose /tmp is mounted as a tmpfs. In that case,
btrfs receive /tmp2 will find /tmp as the longest mount that matches a
prefix of /tmp2 and blow up because it is not a btrfs filesystem, even
if /tmp2 is just a directory in / mounted as btrfs.
Fix this by replacing the substring check with a dirname recursion to
only check the directories in the path of the dir, rather than every
substring.
Add a new test for this case.
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Subvolumes that are part of send must not be deleted, we can check that
only by the error code EPERM, otherwise it's also in the system log.
Signed-off-by: David Sterba <dsterba@suse.com>
Since run_check_stdout() can insert INSTRUMENT for all btrfs related
programs, which could easily pollute the stdout, any caller of
run_check_stdout() should do proper filter.
The following callers are affected:
- misc/004
Filter the output of "btrfs ins min-dev-size"
- misc/009
- misc/013
- misc/024
They are all calling "btrfs ins rootid", so introduce get_subvolid()
function to grab the subvolid properly.
- misc/031
Loose the filter for "btrfs qgroup show". No need for "tail -n 1".
So we still have the same coverage, but now these tests won't cause
false alert if we insert INSTRUMENT for all btrfs commands.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Cleanups done separately:
* use the default test image, loop devices not needed for the test
* trim TEST_MNT from all paths
* send output is created inside the test filesystem
Signed-off-by: David Sterba <dsterba@suse.com>
This test case is the reproducer for the previous fix.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
One reload_btrfs is lost, add it.
Fixes: 0de2e22ad2 ("btrfs-progs: tests: Add tests for changing fsid feature")
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Su Yue <Damenly_Su@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Enhance the prerequisite check for internal tools, up to now missing
btrfs-find-root and btrfs-select-super. The correct path in the checks
is INTERNAL_BIN.
The testsuite is now self-contained.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
As seem in issue #192, this test can fail from time to time. The
issue happens when a mount is issued before the new device is processed
by systemd-udevd, as we can see by the og bellow:
[ 2346.028809] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop10 scanned by systemd-udevd (3418)
[ 2346.265401] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing
[ 2346.272474] BTRFS info (device loop10): disk space caching is enabled
[ 2346.277472] BTRFS info (device loop10): has skinny extents
[ 2346.281840] BTRFS info (device loop10): flagging fs with big metadata feature
[ 2346.308428] BTRFS error (device loop10): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing
[ 2346.315363] BTRFS error (device loop10): failed to read the system array: -2
[ 2346.329887] BTRFS error (device loop10): open_ctree failed
failed: mount /dev/loop10 /home/marcos/git/suse/btrfs-progs/tests//mnt
test failed for case 034-metadata-uuid
make: *** [Makefile:401: test-misc] Error 1
[ 2346.666865] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 2 transid 5 /dev/loop11 scanned by systemd-udevd (3422)
[ 2346.853233] BTRFS: device fsid 1c2debeb-e829-4d6b-84df-aa7c5d246fd5 devid 1 transid 7 /dev/loop6 scanned by systemd-udevd (3418)
A few moments after the test failed systemd-udevd processed the new
device (registered the new device under btrfs). This can be tested by
executing a mount after the test failed, resulting in a successful
mount:
$ mount /dev/loop10 /mnt
[ 2398.955254] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing
[ 2398.959416] BTRFS info (device loop10): disk space caching is enabled
[ 2398.962483] BTRFS info (device loop10): has skinny extents
[ 2398.965070] BTRFS info (device loop10): flagging fs with big metadata feature
[ 2399.012617] BTRFS info (device loop10): enabling ssd optimizations
[ 2399.022375] BTRFS info (device loop10): checking UUID tree
This problem can be avoided is we execute "udevadm settle" before the
mount is executed.
Issue: #192
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Su Yue <Damenly_Su@gmx.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
