The variable 'is_btrfs' is declared as an integer but should be a boolean
instead.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.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>
On aarch64 systems with glibc 2.28, several btrfs-progs test cases are
failing because the command 'btrfs inspect dump-super -a <dev>' reports
an error when it attempts to read beyond the disk/file-image size.
$ btrfs inspect dump-super -a /dev/vdb12
<snap>
ERROR: Failed to read the superblock on /dev/vdb12 at 274877906944
And btrfs/184 also fails, as it uses -s 2 option to dump the last super
block.
$ ./check btrfs/184
FSTYP -- btrfs
PLATFORM -- Linux/aarch64 a4k 6.4.0-rc7+ #7 SMP PREEMPT Sat Jun 24 02:47:24 EDT 2023
MKFS_OPTIONS -- /dev/vdb2
MOUNT_OPTIONS -- /dev/vdb2 /mnt/scratch
btrfs/184 1s ... [failed, exit status 1]- output mismatch (see /Volumes/ws/xfstests-dev/results//btrfs/184.out.bad)
--- tests/btrfs/184.out 2020-03-03 00:26:40.172081468 -0500
+++ /Volumes/ws/xfstests-dev/results//btrfs/184.out.bad 2023-06-24 05:54:40.868210737 -0400
@@ -1,2 +1,3 @@
QA output created by 184
-Silence is golden
+Deleted dev superblocks not scratched
+(see /Volumes/ws/xfstests-dev/results//btrfs/184.full for details)
...
(Run 'diff -u /Volumes/ws/xfstests-dev/tests/btrfs/184.out /Volumes/ws/xfstests-dev/results//btrfs/184.out.bad' to see the entire diff)
Ran: btrfs/184
Failures: btrfs/184
Failed 1 of 1 tests
This is because `pread()` behaves differently on aarch64 and sets
`errno = 2` instead of the usual `errno = 0`.
To fix check if the sb offset is beyond the device size or regular file
size and skip the corresponding sbread().
Also, move putchar('\n') after a successful call to load_and_dump_sb() to
the load_and_dump_sb() itself.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In cmd_inspect_dump_super(), at the label 'out', nothing much happens
other than returning ret.
At the goto statement to the label, in the for loop, we perform close(fd).
However, moving the close(fd) to 'out' as well is not a good idea because
close(fd) doesn't make sense outside the for loop.
Instead, simply return 1 instead of ret=1 and then returning it. Drop both
the 'out' label and ret.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add more error information to help debugging:
$ ./btrfs inspect-internal dump-super -Ffa /dev/vdb10
Before:
ERROR: failed to read the superblock on /dev/vdb10 at 274877906944
After:
ERROR: failed to read the superblock on /dev/vdb10 at 274877906944 read 0/4096 bytes
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
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>
Some test cases are failing when ACL is not compiled in the system.
Instead, they should be marked as 'not_run'.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Bring the 'delete_subvol_children' function under the HAVE_BTRFSUTIL_H
define and fix the following warnings. This function is called only when
'HAVE_BTRFSUTILS_H' is defined.
tests/fsstress.c:1183:1: warning: ‘delete_subvol_children’ defined but not used [-Wunused-function]
1183 | delete_subvol_children(int parid
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Move the entire 'do_fallocate' function under the 'HAVE_LINUX_FALLOC_H'
define and fix the following warnings. This function is called only when
'HAVE_LINUX_FALLOC_H' is defined.
tests/fsstress.c:3814:1: warning: ‘do_fallocate’ defined but not used [-Wunused-function]
3814 | do_fallocate(opnum_t opno, long r, int mode)
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Move the entire 'do_mmap' function under the 'HAVE_SYS_MMAN_H' define
and fix the following warnings. This function is called only when
'HAVE_SYS_MMAN_H' is defined.
tests/fsstress.c:4363:1: warning: ‘do_mmap’ defined but not used [-Wunused-function]
4363 | do_mmap(opnum_t opno, long r, int prot)
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
- use :file: and :command:
- simplify manual page references
- add more web links
- typo fixes
- more cross-references
Signed-off-by: David Sterba <dsterba@suse.com>
Add make command line variable TEST_FROM that takes a glob from where to
start the test sequence. Update docs and fix some trivial typos.
Signed-off-by: David Sterba <dsterba@suse.com>
The build is fine on BE but endianness was broken which prevents mkfs
and anything else on existing images.
Signed-off-by: David Sterba <dsterba@suse.com>
Run release tests after pushing master branch to verify that everything
is ok, also trigger the static build so there are binaries built with
the new version tag.
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Command `btrfs scrub start -B` and `btrfs scrub status` are reporting
very different results for "Total to scrub":
$ sudo btrfs scrub start -B /mnt/btrfs/
scrub done for c107ef62-0a5d-4fd7-a119-b88f38b8e084
Scrub started: Mon Jun 5 07:54:07 2023
Status: finished
Duration: 0:00:00
Total to scrub: 1.52GiB
Rate: 0.00B/s
Error summary: no errors found
$ sudo btrfs scrub status /mnt/btrfs/
UUID: c107ef62-0a5d-4fd7-a119-b88f38b8e084
Scrub started: Mon Jun 5 07:54:07 2023
Status: finished
Duration: 0:00:00
Total to scrub: 12.00MiB
Rate: 0.00B/s
Error summary: no errors found
This can be very confusing for end users.
[CAUSE]
It's the function print_fs_stat() handling the "Total to scrub" output.
For `btrfs scrub start` command, we use the used bytes (aka, the total
used dev extents of a device) for output.
This is not really accurate, as the chunks may be mostly empty just like
the following:
$ btrfs fi df /mnt/btrfs/
Data, single: total=1.01GiB, used=9.06MiB
System, DUP: total=40.00MiB, used=64.00KiB
Metadata, DUP: total=256.00MiB, used=1.38MiB
GlobalReserve, single: total=22.00MiB, used=0.00B
Thus we're reporting 1.5GiB to scrub (1.01GiB + 40MiB * 2 + 256MiB * 2).
But in reality, we only scrubbed 12MiB
(9.06MiB + 64KiB * 2 + 1.38MiB * 2).
[FIX]
Instead of using the used dev-extent bytes of a device, go with proper
scrubbed bytes for each device.
This involves print_fs_stat() and print_scrub_dev() called inside
scrub_start().
Now the output should match each other.
Issue: #636
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
There is a bug report that on s390x big endian systems, mkfs.btrfs just
fails:
$ mkfs.btrfs -f ~/test.img
btrfs-progs v6.3.1
Invalid mapping for 1081344-1097728, got 17592186044416-17592190238720
Couldn't map the block 1081344
ERROR: cannot read chunk root
ERROR: open ctree failed
[CAUSE]
The error is caused by wrong endian conversion. The s390x is a big
endian architecture:
$ lscpu
Byte Order: Big Endian
While checking the offending @disk_key and @key inside
btrfs_read_sys_array(), we got:
2301 while (cur_offset < array_size) {
(gdb)
2304 if (cur_offset + len > array_size)
(gdb)
2307 btrfs_disk_key_to_cpu(&key, disk_key);
(gdb)
2310 sb_array_offset += len;
(gdb) print *disk_key
$2 = {objectid = 281474976710656, type = 228 '\344', offset = 17592186044416}
(gdb) print key
$3 = {objectid = 281474976710656, type = 228 '\344', offset = 17592186044416}
(gdb)
Now we can see, @disk_key is indeed in the little endian, but @key is
not converted to the CPU native endian.
Furthermore, if we step into the help btrfs_disk_key_to_cpu(), it shows
we're using little endian version:
(gdb) step
btrfs_disk_key_to_cpu (disk_key=0x109fcdb, cpu_key=0x3ffffff847f)
at ./kernel-shared/accessors.h:592
592 memcpy(cpu_key, disk_key, sizeof(struct btrfs_key));
[FIX]
The kernel accessors.h checks if __LITTLE_ENDIAN is defined or not, but
that only works inside kernel.
In user space, __LITTLE_ENDIAN and __BIG_ENDIAN are both provided by
kerncompat.h that should have been included already.
Instead we should check __BYTE_ORDER against __LITTLE_ENDIAN to
determine our endianness.
With this change, s390x build works as expected now.
Issue: #639
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The remount workflow could cause some problems so make a note about it.
Recommend the umount/mount step by default. A seeding device used for
e.g. a root filesystem that gets updated and has snapshots is a real
world example where the space consumed by unreclaimed deleted snapshots
would hurt.
Pull-request: #462
Author: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
mkfs.btrfs help message for --quiet is 'no message except errors' so
we probably ought to silence this as well in the quiet case.
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Other pages list the latest version first, do that here as well. Also
reorder index so the features are first before version changelogs.
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
We got some test failures related to btrfs-convert with subpage, e.g.
btrfs/012, the failure would cause the following dmesg:
BTRFS warning (device nvme0n1p7): v1 space cache is not supported for page size 16384 with sectorsize 4096
BTRFS error (device nvme0n1p7): open_ctree failed
[CAUSE]
v1 space cache has tons of hard coded PAGE_SIZE usage, and considering
v2 space cache is going to replace it (which is already the new default
since v5.15 btrfs-progs), thus for btrfs subpage support, we just simply
reject the v1 space cache, and utilize v2 space cache when possible.
But there is special catch in btrfs-convert, although we're specifying
v2 space cache as the new default for btrfs-convert, it doesn't really
follow the specification at all.
Thus the converted filesystem will still go v1 space cache.
[FIX]
It can be a huge change to btrfs-convert to make the initial btrfs image
to support v2 cache.
Thus this patch would change the fs at the final stage, just before we
finalize the btrfs.
This patch would drop all the v1 cache created, then call
btrfs_create_free_space_tree() to populate the free space tree and
commit the superblock with needed compat_ro flags.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add the DEF_SUPER_FLAG_ENTRY for CHANGING_FSID_V2 to our btrfs-progs'
print-tree.c, as it is currently missing in the dump-super output, which
was too confusing.
Before:
flags 0x1000000001
( WRITTEN )
After:
flags 0x1000000001
( WRITTEN |
CHANGING_FSID_V2 )
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Print the source directory for --rootdir and if --shrink is used. With
-vv then print the individual files as added:
$ mkfs.btrfs --rootdir dir --shrink -vv img
...
Rootdir from: Documentation
ADD: /btrfs-progs/Documentation/btrfs-check.rst
...
ADD: /btrfs-progs/Documentation/btrfs-send.rst
Shrink: yes
Label: (null)
UUID: 40d3a16f-02d8-40d7-824b-239cee528093
...
The 'Rootdir from' is printed before the files are added so there's now
message before the files are added which could take some time.
Issue: #627
Signed-off-by: David Sterba <dsterba@suse.com>
Move files from m4/ to config that is also used for build and we can
reduce the number of toplevel directories.
Signed-off-by: David Sterba <dsterba@suse.com>
If I run autoreconf -fi in btrfs-progs repo in VirtualBox, it fails with
possibly undefined macro AC_DEFINE. To fix this, I added m4 as the macro
directory in configure.ac as follows. Adding that line fixes the error
when running autoreconf.
Versions:
autoreconf 2.69
automake 1.15.1
btrfs-progs v6.3-fba31d63
openSUSE 15.5
VirtualBox 6.1.40
configure.ac:7: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:63: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:276: error: possibly undefined macro: AC_MSG_WARN
autoreconf: /usr/bin/autoconf failed with exit status: 1
Issue: #632
Signed-off-by: David Sterba <dsterba@suse.com>
More complete test coverage:
- json an string table formatters
- fuzz tests (no mount)
- libbtrfs build test
- libbtrfsutil python test
- ioctl build test
- hash tests
Signed-off-by: David Sterba <dsterba@suse.com>
The links to repositories and contributors is hard to find as it's below
the feature list. Move it up as it is for overview.
Signed-off-by: David Sterba <dsterba@suse.com>
There are reports that json output of 'qgroup show' crashes due to
internal error when printing the limit values:
INTERNAL ERROR: unknown unit base, mode 2304
btrfs(internal_error+0x10a)[0x5605c37ce48a]
btrfs(pretty_size_snprintf+0x5c)[0x5605c37d105c]
btrfs(fmt_print+0x44e)[0x5605c37d178e]
btrfs(+0x7ed1d)[0x5605c3800d1d]
btrfs(main+0x8f)[0x5605c379beff]
/lib64/libc.so.6(+0x27bb0)[0x7f83924ddbb0]
/lib64/libc.so.6(__libc_start_main+0x8b)[0x7f83924ddc79]
btrfs(_start+0x25)[0x5605c379d405]
common/units.c:82: pretty_size_snprintf: Assertion `0` failed, value 0
btrfs(+0x1d4b1)[0x5605c379f4b1]
btrfs(pretty_size_snprintf+0x7b)[0x5605c37d107b]
btrfs(fmt_print+0x44e)[0x5605c37d178e]
btrfs(+0x7ed1d)[0x5605c3800d1d]
btrfs(main+0x8f)[0x5605c379beff]
/lib64/libc.so.6(+0x27bb0)[0x7f83924ddbb0]
/lib64/libc.so.6(__libc_start_main+0x8b)[0x7f83924ddc79]
btrfs(_start+0x25)[0x5605c379d405]
This is caused by "size" format that requires the unit mode, but it was not
specified and some stack value used. As json prints the raw values, use
the plain %llu format.
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1206960
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1209136#c15
Signed-off-by: David Sterba <dsterba@suse.com>
Currently "btrfstune --csum" allows us to change the csum to the same
one, this is good for testing but not good for end users, as if the end
user interrupts it, they have to resume the change (even it's to the
same csum type) until it finished, or kernel would reject such fs.
Furthermore, we never change the super block csum type until we
completely changed the csum type, thus for resume cases, the fs would
still show up as using the old csum type thus won't cause any problem
resuming.
So here we just reject the csum conversion if the target csum type is
the same as the existing csum type.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When the csum conversion is interrupted when changing data csum
objectid, we should just resume the objectid conversion.
This situation can be detected by comparing the old and new csum items.
They should both exist but doesn't intersect (interrupted halfway), or
only new csum items exist (interrupted after we have deleted old csums).
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If the csum conversion is interrupted when old csums are being deleted,
we should resume by continue deleting the old csums.
The function delete_old_data_csums() can handle half deleted cases
already.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We have a very rare chance to hit a fs with empty csum tree but still
has CHANGING_DATA_CSUM flag.
The window is very small, but it's still possible, so handle it by
jumping directly to metadata csum change.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
