Currently some instances of btrfs_free_extent are called with the
last parameter ("offset") being set to 1. This makes no sense, since
offset is used for data extents. I suspect this is a left-over from
95d3f20b51 ("Mixed back reference (FORWARD ROLLING FORMAT CHANGE)")
since this commit changed the signature of the function from :
-int btrfs_free_extent(struct btrfs_trans_handle *trans, struct btrfs_root
- *root, u64 bytenr, u64 num_bytes, u64 parent,
- u64 root_objectid, u64 ref_generation,
- u64 owner_objectid, int pin);
to
+int btrfs_free_extent(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root,
+ u64 bytenr, u64 num_bytes, u64 parent,
+ u64 root_objectid, u64 owner, u64 offset);
I.e the last parameter was "pin" and not offset. So these are just
leftovers with no semantic meaning. Fix this by passing 0.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This is not really needed, since we can reference the fs_info from the
passed transaction. This is in preparation for delayed-refs support.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This argument is no longer used in this function so remove it.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
They are not really needed, what free_extent_hook wants is really a
pointer to fs_info so give it to it directly. This is in preparation
of delayed refs code.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This is in preparation of delayed refs code.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Instead of updating this during update_block_group, move the updating
code at the places where we free/allocate a block. This resembles the
current state of the kernel code. This is in prep for delayed refs.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Pull the necessary function, excluding locking. Required to enable
integration of delayed refs.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It's not needed, since we can obtain a reference to fs_info from the
passed transaction handle. This is needed by delayed refs code.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This argument is used to obtain a reference to fs_info, which can
already be done from the passed trans handle, so use that instead.
This is in preparation for delayed refs support.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It does not 't build anymore and we don't have any use for it.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When btrfs check detects a freespace tree extent which ends beyond the
blockgroup containing it a misleading error messages is printed. For
example if we have the following extent in the freespace tree:
item 5 key (30408704 FREE_SPACE_INFO 1073741824) itemoff 16259 itemsize 8
free space info extent count 3 flags 0
item 6 key (30425088 FREE_SPACE_EXTENT 49152) itemoff 16259 itemsize 0
free space extent
item 7 key (30507008 FREE_SPACE_EXTENT 65536) itemoff 16259 itemsize 0
free space extent
item 8 key (30654464 FREE_SPACE_EXTENT 14524648038063310901) itemoff 16259 itemsize 0
Clearly the last extent is corrupted so we should print something
along the lines of:
free space extent ends at 14524648038063310901, beyond end of block group 30408704-1104150528
Instead currently this is printed:
free space extent ends at 30654464, beyond end of block group 30408704-1104150528
So instead of printing the actual erroneous end, we print the beginning
of the extent. Fix this by printing the actual corrupted end.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For easier debugging, let print_tree_block_error() print bytenr of tree
block.
Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Update the information to reflect the status of 4.18
Main Updates:
- Add explanation of improved compression heuristic algorithm
- Add explanation that norecovery == nologreplay
- Add explanation of nossd_spread mount option
- Add explanation of rmdir_subovl feature
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
[ minor updates ]
Signed-off-by: David Sterba <dsterba@suse.com>
Don't panic for btrfs_read_chunk_tree() if one device or chunk is
corrupted.
Caller can already handle it pretty well.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199839
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The experimental flag is already carried in the manpage, but was removed
from the btrfs check usage message as part of refactoring via
87c1bd13c1. Add it back.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Similar to the original mode repair.
Reported-by: Steve Leung <sjleung@shaw.ca>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Current check_file_extent() doesn't support later repair work, since it
doesn't accept btrfs_path structure as parameter, thus it can't modify
btrfs trees, or later check will still use the old and wrong path.
Use btrfs_path to replace btrfs_key, extent_buffer and slot parameters,
so we can modify @path directly for repair, and reduce the number of
parameters for check_file_extent().
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It looks like that around 2014, btrfs kernel has a regression that would
cause offset-by-one ram_bytes for inline extent.
Add the ability to repair it in original mode.
Reported-by: Steve Leung <sjleung@shaw.ca>
Tested-by: Steve Leung <sjleung@shaw.ca>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
If one uncompressed inline extent has incorrect ram_bytes, neither btrfs
check nor dump-tree could detect such corruption.
[CAUSE]
Every caller tries to read inline extent ram_bytes is using
btrfs_file_extent_inline_len(), other than directly calling
btrfs_file_extent_ram_bytes().
For compressed extent, it's just calling btrfs_file_extent_ram_bytes().
However for uncompressed extent, it falls back to
btrfs_file_extent_inline_item_len(), makes us unable to detect anything
wrong in ram_bytes.
[FIX]
Just get rid of such confusing btrfs_file_extent_inline_len() function.
Reported-by: Steve Leung <sjleung@shaw.ca>
Tested-by: Steve Leung <sjleung@shaw.ca>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When using decompress() in copy_one_inline(), we're passing the
decompressed extent size (ram_bytes) into decompress().
However we only has @inline_item_len read out, the pending data will be
uninitialized data.
Thankfully, all compression methods supported have some extra data in
its header, thus it won't cause real problem.
Whatever fixing it is never a bad idea.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In btrfs_add_free_space(), if the free space to be added is already
here, we trigger ASSERT() which is just another BUG_ON().
Let's remove such BUG_ON() at all.
Reported-by: Lewis Diamond <me@lewisdiamond.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
check_chunks_and_extents does quite a number of distinct things. The
first of those is going through all root items in the root tree and
classify every root depending on whether they have a dropping operation
in progress or not. Lets factor out this code and move the variables
specific to this in a separate function so clean up check_chunks_and_extents
a bit. Accidentally, this patch fixes some reference leaks since
in error conditions in the loop the code does "goto out" but at that
label we don't really release the path. Having this code extracted in a
separate function which always releases the path avoids this problem
entirely.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The first thing that check_chunks_and_extents does is to iterate all
the root items in the root tree and link them to either the "normal_list"
or "dropping_trees" list. If a leaf has to be crossed during this
operation btrfs_next_leaf is called to do that. However, currently it's
called with a wrong argument for its 'root' parameter. Since we are
iterating the root tree the passed root should be fs_info->tree_rot,
whereas right now we are passing the local variable 'root' which is
assigned to the fs_tree. As it stands, this bug is actually benign since
the passed root is only passed to reada_for_search, where it's used to
reference the fs_info. Nevertheless the code is wrong and at the very least
misleading, so fix it by passing the correct root.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Test misc/029 only works if the test case is executed as root, while for
sudo usage, it doesn't work as initial mkdir and final cleanup doesn't
use $SUDO_HELPER.
Add "run_check $SUDO_HELPER" for such cases to allow it works under sudo
usage.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In function handle_global_options(), we reset @optind to 1.
However according to man page of getopt(3) NOTES section, if we need to
rescan options later, @optind should be reset to 0 to initialize the
internal variables correctly.
This explains the reason why in cmd_check(), getopt_long() doesn't
handle the following command correctly:
"btrfs check /dev/data/btrfs --check-data-csum"
While mkfs.btrfs handles mixed non-option and option correctly:
"mkfs.btrfs -f /dev/data/disk1 --data raid1 /dev/data/disk2"
Cc: Paul Jones <paul@pauljones.id.au>
Cc: Hugo Mills <hugo@carfax.org.uk>
Fixes: 010ceab56e ("btrfs-progs: rework option parser to use getopt for global options")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We'll want to pass non-default superblock flags so let's use the other
helper that allows that. We can reuse the filesystem handle so it needs
to open it read-write, unlike what the plain check_mounted does.
Signed-off-by: David Sterba <dsterba@suse.com>
New flag that mimics OPEN_CTREE_IGNORE_FSID_MISMATCH but only for
reading the superblock. It should be passed around to various helpers
like scan or mount checks as they'd fail before we'd get to the final
caller that can do something useful with the filesystem.
This will be used for an interrupted 'btrfstune -u'.
Note to __open_ctree_fd: the RECOVERY mode is not compatible with that
flag
Signed-off-by: David Sterba <dsterba@suse.com>
Extend check_mounted_where so we can pass additional flags that would
allow us to open filesystem in some specific state. This will be used
for a filesystem that has a partially changed uuid.
Signed-off-by: David Sterba <dsterba@suse.com>
We use rb_entry all over the place for the root_info pointers. Add
a helper to make the code more readable.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It's unlikely we're going to modify a pathname argument, so codify that
and use const.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In print_single_qgroup_table we check the loop index against
BTRFS_QGROUP_CHILD, but what we really mean is "last column." Since
we have an enum value to indicate the last value, use that instead
of assuming that BTRFS_QGROUP_CHILD is always last.
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Initialize all filed of btrfs_inode_item to zero in order to prevent
having some garbage, especially for flags field.
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The restore target file does not exist and creating by root does not
work on NFS, so precreating will make that work. Also fix the image name
to be deleted.
Signed-off-by: David Sterba <dsterba@suse.com>
In case of RAID10, fi usage is reporting half the amount of allocated
space and twice the amount of unallocated disk space. Let's fix this.
For example, a RAID10 chunk of 3GiB with num_stripes 6, half of the
stripes (dev extents) are a mirror of the other half, so the 3GiB of
actual data has to be divided by 3, and not 6 to get the size of each of
those device extents.
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Signed-off-by: David Sterba <dsterba@suse.com>
In case add_inode_items returned -EEXIST, traverse_directory would
handle the condition and still continue under certain circumstances, but
it would not reset the error code, leading to spurious failure later.
This patch fixes that.
Pull-request: #124
Author: Matthias Benkard <matthias.benkard@egym.de>
Signed-off-by: David Sterba <dsterba@suse.com>
Fix subvol_strip_mountpoint for mnt="/" (len=1). In this case, skip
check for trailing slash on full_path (leading slash on full_path is
already asserted by strncmp).
Issue: #122
Pull-request: #138
Fixes: c5dc299aff ("btrfs-progs: prevent incorrect use of subvol_strip_mountpoint")
Signed-off-by: Axel Burri <axel@tty0.ch>
Signed-off-by: David Sterba <dsterba@suse.com>
Since the out label has been deleted, this free_extent_buffer will never
be executed.
Fixes: f37ae8d275 ("btrfs-progs: print-tree: Enhance warning on tree block level mismatch and error handling")
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently the -D option is essentially defunct since it's the root,
where we are going to corrupt a dir item is always set to the tree
root. Fix this by passing the root from the "-r" option. Aditionally
convert the interface for this option to the new format. So if one
wants to corrupt a dir item in the default fs tree, they should now
invoke:
btrfs-corrupt-block -r 5 -D <objectid,DIR_ITEM,offset> -f name
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently if we want to delete an item we need to invoke corrupt block
like so:
btrfs-corrupt-block [-r <numeric id of root>] -K <objectid,type,offset> -d
Instead, this patch converts the format to:
btrfs-corrupt-block [-r <numeric id of root>] -d <objectid,type,offset>
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently the -K option supports corrupting items only in the default
root (which is the root tree). This makes it impossible to test the
free-space recovery (or any other) code for that matter. Fix it by
using the root corresponding to the one passed in -r (if any).
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Since more and more of the "corrupt XXX" options are going to support
combination with -r option, let's extract the common code needed for
this. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There is now a common function used to parse btrfs keys triplets so
use that one. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Presently, if we want to corrupt a particular item we need to call
corrupt block like so:
btrfs-corrupt-block -I -K <objectid,type,offset> -r "numeric rootid"
This is problematic because the -K option not only sets the key to the
item that the -I option should corrupt but it also signals that we
want to corrupt the key itself. This way we cannot really use the
program with the following semantics:
"Corrupt only the item which corresponds to this key but leave the
key intact"
This patch aims to fix this by changing the format of the -I flag. So
if one wants to corrupt only an item (and leave the key intact) they
should use:
btrfs-corrupt-block -r <numeric rootid> -I <objectid,type,offset>
In addition to this problem, -K doesn't really understand the the "-r"
argument, so when using it in conjunction with -I to corrupt an item,
not part of the root tree, it will always produce an error:
Couldn't find the key to corrupt
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
