Enhance the note what scrub does not compared to 'check'.
Author: Andrea Gelmini <andrea.gelmini@gelma.net>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit e578b59bf6 ("btrfs-progs: convert strerror to implicit %m")
missed adding braces after a conditional so we will see the following
message whenever a tree block needs repair, regardless of whether repair
was successful: "Failed to repair btree: Success"
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Starting device replace and balance does not properly report the status.
1. start replace:
$ btrfs replace start -B -f /dev/sdd /dev/sdb /btrfs
2. while replace is still running, from another terminal try to start
balance:
$ btrfs balance start --full-balance /btrfs
Done, had to relocate 0 out of 0 chunks
This returns with exit code 0, which fails to report that balance failed
to start because another exclusive operation is running.
In fact kernel ioctl BTRFS_IOC_BALANCE(_V2) does return error code 8,
but it's incorrectly reset to 0. Fix it by checking for the error code > 0.
After:
$ btrfs balance start --full-balance /btrfs
ERROR: balance: add/delete/balance/replace/resize operation in progress
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Add a test for a scenario that used to fail due to find_mount_root()
incorrectly determining the mount point for the receive path due to the
fact that a different mount point with a path that is a prefix of the
receive path exists.
This is fixed by a recent patch titled:
"Btrfs-progs: fix mount point detection due to partial prefix match"
Reported-by: David Disseldorp <ddiss@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
[ adjustments to make the test work when hosted on NFS ]
Signed-off-by: David Sterba <dsterba@suse.com>
The strdup() function can fail, in which case it returns NULL and sets
errno [1]. Therefore add the missing error check after calling strdup()
at find_mount_root().
[1] - http://man7.org/linux/man-pages/man3/strdup.3p.html
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When attempting to find the mount point of a path we can end up returning
an incorrect mount point. This happens because we consider a mount point
valid for the given path even if it only partially matches the path.
Consider the following example, which makes btrfs receive fail:
$ truncate -s 1G disk1
$ truncate -s 1G disk2
$ losetup /dev/loop1 disk1
$ losetup /dev/loop2 disk2
$ mkfs.btrfs -f /dev/loop1
$ mkfs.btrfs -f /dev/loop2
$ mount /dev/loop1 /mnt
$ mkdir /mnt/ddis
$ mkdir /mnt/ddis-not-a-mount
$ mount /dev/loop2 /mnt/ddis
$ echo "some data" > /mnt/ddis/file
$ btrfs subvolume snapshot -r /mnt/ddis /mnt/ddis/snap
$ btrfs send -f /tmp/send.data /mnt/ddis/snap
$ btrfs receive -f /tmp/send.data /mnt/ddis-not-a-mount
At subvol snap
ERROR: chown failed: No such file or directory
In that example btrfs receive passes the path "/mnt/ddis-not-a-mount" to
find_mount_root() which picks "/mnt/ddis" as the mount point instead of
"/mnt". The wrong decision happens because "/mnt/ddis" is the longest
string found that is a prefix of "/mnt/ddis-not-a-mount", however it
shouldn't be considered valid because what follows the substring "ddis"
in the given path is not a path separator ("/") nor the null character
('\0'). So fix find_mount_root() to check for the presence of a path
separator or a null byte character after if finds a mount point string
that matches the given path.
A test case will follow soon in a separate patch.
Reported-by: David Disseldorp <ddiss@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Provide an 'etags' make target to create tags in the Emacs etags
format, similar to the 'tags' target for VIM's ctags.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: David Sterba <dsterba@suse.com>
This function provides the offline functionality to add new uuid tree
entry. Also port fs_info->uuid and its initialization and cleanup code
to support uuid tree.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Although we have btrfs_uuid_tree_lookup_any(), it's an online function
utilizing tree search ioctl, not an offline search function.
This patch will port kernel btrfs_uuid_tree_lookup() into btrfs-progs
for later proper uuid tree initialization.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For data reloc tree creation, we copy its contents from the fs tree just
for its INODE_ITEM, INODE_REF and dirid. This hides the detail and is
not obvious for why we're copying from fs root.
This patch will create data reloc tree from scratch:
- Create root, including root item and new tree root
- Change dirid to BTRFS_FIRST_FREE_OBJECTID
- Insert root INODE_ITEM and INODE_REF
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Just as how kernel uses it.
This provides the basis for later uuid creation.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add the section with brief summary of the support. The supported
features could be mentioned explicitly with versions, and other examples
of "check before use" that could lead to unbootable systems.
Signed-off-by: David Sterba <dsterba@suse.com>
The runtime of the test is over 4 minutes when hosted on NFS, the
fallocate phase takes the most time. As fallocate can't take multiple
arguments, we can't save the overhead by creating the files at once.
Create the files in batches in the background, this improves the runtime
to 2 minutes.
Signed-off-by: David Sterba <dsterba@suse.com>
The repair function is reusing delete_corrupted_dir_item().
Since the error can happen for root dir inode, also call
try_repair_inode() on root dir inode.
This is especially important for old filesystems, since later kernel
introduces stricter tree-checker, which could detect such hash mismatch
and refuse to read the corrupted leaf.
With this repair ability, user could repair with btrfs check --repair.
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1111991
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This changes reporting from current in-place, like:
ERROR: DIR_ITEM[256 751495445] name foor.WvG1c1TdU namelen 13 filetype 1 mismatch with its hash, wanted 751495445 have 2870353892
root 5 root dir 256 error
To new summary report at the end of the pass:
root 5 root dir 256 error
root 5 inode 256 errors 40000
Dir items with mismatch hash:
name: foor.WvG1c1Td namelen: 13 wanted 0xab161fe4 has 0x2ccae915
Also, with mismatch_dir_hash_record structure, it provides the base for
later original mode repair.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For DIR_ITEM with mismatch hash, we could just remove the offending dir
item from the tree.
Lowmem mode will handle the rest, either re-create the correct dir_item
or move the orphan inode to lost+found.
This is especially important for old filesystems, since later kernel
introduces stricter tree-checker, which could detect such hash mismatch
and refuse to read the corrupted leaf.
With this repair ability, user could repair with 'btrfs check
--mode=lowmem --repair'.
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1111991
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There's a suggestion in #158 to improve the documenatation of the subvol
show command so it's more obvious what kind of information it provides.
I've updated the docs according to that and added an example that should
make the request for creation time at least greppable, the overall
description mentions 'times' so this should be enough as a pointer.
Pull-request: #158
Suggested-by: Robert Pollak <robert.pollak@posteo.net>
Signed-off-by: David Sterba <dsterba@suse.com>
Now two locations can detect such problem, either by device item
used/total bytes check, or by early dev extents check against device
boundary.
The image is hand-crafted image which uses DATA SINGLE chunk to feed
btrfs check. As expected, as long as block group item, chunk item,
device used bytes match, older versions check can't detect such problem.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Unlike lowmem mode check, we don't have good place for original mode to
check overlapping device extents.
So this patch introduces a new function, btrfs_check_dev_extents(), to
handle such extents.
Reported-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add such check to check_dev_item(), since at that time we're also
iterating dev extents for dev item accounting.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
misc-test/021 will fail with the following error message:
====== RUN CHECK root_helper btrfs-progs/btrfs-image -r btrfs-progs/tests//test.img /dev/loop2
ERROR: failed to enlarge result image: Invalid argument
ERROR: failed to fix chunks and devices mapping, the fs may not be mountable: Invalid argument
extent buffer leak: start 30638080 len 16384
extent buffer leak: start 30408704 len 16384
WARNING: dirty eb leak (aborted trans): start 30408704 len 16384
ERROR: restore failed: Invalid argument
failed: root_helper btrfs-progs/btrfs-image -r btrfs-progs/tests//test.img /dev/loop2
test failed for case 021-image-multi-devices
[CAUSE]
For misc-test/021, we're using loopback device, which doesn't support
ftruncate. That's why it returns EINVAL.
[FIX]
Only call ftruncate64() if we're operating on a regluar file.
Fixes: a7a44164c84e ("btrfs-progs: image: Use correct device size when restoring")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When restoring btrfs image, the total_bytes of device item is not
updated correctly. In fact total_bytes can be left 0 for restored image.
It doesn't trigger any error because btrfs check never checks
total_bytes of dev item. However this is going to change.
Fix it by populating total_bytes of device item with the end position of
last dev extent to make later btrfs check happy.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
messages.h:49:24: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
PRINT_TRACE_ON_ERROR; \
Use empty statement in the macro defintions that are now empty.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
set_free_space_tree_thresholds() is never used, just remove it to solve
the missing-prototypes warning from make W=1.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Prototypes for arg_strtou64() and lookup_path_rootid() are included in
utils.c, resulting make W=1 warning for them.
Just include that header to make W=1 happier.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We don't have any header declaring btrfs_recover_chunk_tree() nor
btrfs_recover_superblocks(), thus W=1 gives missing-prototypes warning
on them.
Fix it by introducing a new header, rescue.h for these two functions, so
make W=1 could be much happier.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
And fsfeatures.c is indeed a better location for that function.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
GCC 8.2.1 will report the following warning with "make W=1":
ctree.c: In function 'btrfs_next_sibling_tree_block':
ctree.c:2990:21: warning: 'slot' may be used uninitialized in this function [-Wmaybe-uninitialized]
path->slots[level] = slot;
~~~~~~~~~~~~~~~~~~~^~~~~~
The culprit is the following code:
int slot; << Not initialized
int level = path->lowest_level + 1;
BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
while(level < BTRFS_MAX_LEVEL) {
slot = path->slots[level] + 1;
^^^^^^ but we initialize @slot here.
...
}
path->slots[level] = slot;
It's possible that compiler doesn't get enough hint for BUG_ON() on
lowest_level + 1 >= BTRFS_MAX_LEVEL case.
Fix it by using a do {} while() loop other than while() {} loop, to
ensure we will run the loop for at least once.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The only hit is the following code:
tlv_len = le16_to_cpu(tlv_hdr->tlv_len);
if (tlv_type == 0 || tlv_type > BTRFS_SEND_A_MAX
|| tlv_len > BTRFS_SEND_BUF_SIZE) {
error("invalid tlv in cmd tlv_type = %hu, tlv_len = %hu",
tlv_type, tlv_len);
@tlv_len is u16, while BTRFS_SEND_BUF_SIZE is 64K.
u16 MAX is 64K - 1, so the final check is always false.
Just remove it.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Although most fallthrough cases are pretty obvious, we still need to
teach hint the compiler that it's an explicit fallthrough. The
annotation is not standardized and sometimes comments are used, the
attribute is getting more widespread so we're going to use it too.
Unknown attributes are ignored by old compilers.
Also reformat the code to use common indentation.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Under most case, we are just using 'int' for 'unsigned int', and doesn't
care about the sign.
The -Wsign-compare warning is causing tons of false alerts. Suppressing
it makes W=1 less noisy so we can focus on real problems, while still
allowing it in W=3 build.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When using gcc8 + glibc 2.28.5 compiles utils.c, it complains as below:
utils.c:852:45: warning: '%s' directive output may be truncated writing
up to 4095 bytes into a region of size 4084 [-Wformat-truncation=]
snprintf(path, sizeof(path), "/dev/mapper/%s", name);
^~ ~~~~
In file included from /usr/include/stdio.h:873,
from utils.c:20:
/usr/include/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk'
output between 13 and 4108 bytes into a destination of size 4096
return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This isn't a type of warning we care about, particularly when calling
snprintf() we expect string to be truncated.
Use the GCC option -Wno-format-truncation to disable this for default
build and W=1 build, while still keeping it for W=2 and W=3 builds.
Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
[ Use cc-disable-warning to fix the not working CFLAGS setting in configure.ac ]
[ Keep the warning in W=2/W=3 build ]
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We imported cc-option but forgot to import cc-disable-warning.
Fixes: b556a992c3 ("btrfs-progs: build: allow to build with various compiler warnings")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
I apparently didn't test this on a pre-4.18 kernel.
test_subvolume_info_unprivileged() checks for an ENOTTY, but this
doesn't seem to work correctly with subTest().
test_subvolume_iterator_unprivileged() doesn't have a check at all. Add
an explicit check to both before doing the actual test.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add a bunch of tests exercising the new btrfstune functionality. In
particular check that various restrictions are implemented correctly,
test that btrfs-image works as expected and also test the output of
btrfs inspect-internal dump-super is correct.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This function currently takes an fs_info only to reference the chunk
root. Just pass the root directly. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This member was used only by btrfstune when using the old method to
change fsid. It's only an in-memory value with a very specific
purpose so it makes no sense to pollute a generic structure such as
btrfs_fs_info with it. Just remove it and pass it as a function
argument where pertinent. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This allows us to change the use-visible UUID on filesytems from
userspace if desired, by copying the existing UUID to the new location
for metadata comparisons. If this is done, an incompat flag must be
set to prevent older filesystems from mounting the filesystem, but
the original UUID can be restored, and the incompat flag removed.
This introduces the new -m|-M UUID options similar to current
-u|-U UUID ones with the difference that we don't rewrite the fsid but
just copy the old uuid and set a new one. Additionally running with
[-M old-uuid] clears the incompat flag and retains only fsid on-disk.
Additionally it's not allowed to intermix -m/-u/-U/-M options in a
single invocation of btrfstune, nor is it allowed to change the uuid
while there is a uuid rewrite in-progress. Also changing the uuid of a
seed device is not currently allowed (can change in the future).
Example:
btrfstune -m /dev/loop1
btrfs inspect-internal dump-super /dev/loop1
superblock: bytenr=65536, device=/dev/loop1
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x4b7ea749 [match]
<ommitted for brevity>
fsid 0efc41d3-4451-49f3-8108-7b8bdbcf5ae8
metadata_uuid 352715e7-62cf-4ae0-92ee-85a574adc318
<ommitted for brevity>
incompat_flags 0x541
( MIXED_BACKREF |
EXTENDED_IREF |
SKINNY_METADATA |
METADATA_UUID )
<omitted for brevity>
dev_item.uuid 0610deee-dfc3-498b-9449-a06533cdec98
dev_item.fsid 352715e7-62cf-4ae0-92ee-85a574adc318 [match]
<ommitted for brevity>
mount /dev/loop1 btrfs-mnt/
btrfs fi show btrfs-mnt/
Label: none uuid: 0efc41d3-4451-49f3-8108-7b8bdbcf5ae8
Total devices 1 FS bytes used 128.00KiB
devid 1 size 5.00GiB used 536.00MiB path /dev/loop1
In this case a new btrfs filesystem was created and the original uuid
was 352715e7-62cf-4ae0-92ee-85a574adc318, then btrfstune was run which
copied that value over to metadata_uuid field and set the current fsid
to 0efc41d3-4451-49f3-8108-7b8bdbcf5ae8. And as far as userspace is
concerned this is the fsid of the fs.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add support for a new metadata_uuid field. This is just a preparatory
commit which switches all users of the fsid field for metdata comparison
purposes to utilize the new field. This more or less mirrors the
kernel patch, additionally:
* Update 'btrfs inspect-internal dump-super' to account for the new
field. This involes introducing the 'metadata_uuid' line to the
output and updating the logic for comparing the fs uuid to the
dev_item uuid.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Test case misc/021 is testing if we could mount a single disk btrfs
image recovered from multi disk fs.
The problem is, current kernel has extra check for block group, chunk
and dev extent. This means no image can pass btrfs check for chunk
tree and the filesystem will not mount.
So do extra btrfs check before mount, this will also help us to locate
the problem in btrfs-image easier.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Andrea Gelmini