In the new add_extent_rec_nolookup() function, we add bytes_used to
update found bytes accounting.
However there is a typo that we used tmpl->nr, which should be rec->nr.
This will make us to add 1 for data backref, instead the correct size.
Reported-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The extent record's max_size might be 0 and the stripe crossing check
will report a false positive, should use the filesyste nodesize. There's
a global fs_info available.
Signed-off-by: David Sterba <dsterba@suse.com>
Similar to add_extent_rec_nolookup, pass the arguments via a temporary
structure. In case the extent is found, some of the values are not
assigned directly so the semantics is preserved.
Signed-off-by: David Sterba <dsterba@suse.com>
There are just 3 values of flag_block_full_backref, we can utilize a
bitfield and save 8 bytes (192 now).
Signed-off-by: David Sterba <dsterba@suse.com>
Reduce number of parameters that just fill the extent_record from a
temporary template that's supposed to be zeroed and filled by the
callers.
Signed-off-by: David Sterba <dsterba@suse.com>
Before this patch, although btrfsck will check qgroups if quota is
enabled, it always return 0 even qgroup numbers are corrupted.
Fix it by allowing return value from report_qgroups function (formally
defined as print_qgroup_difference).
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Separate the part of add_extent_rec that comes after the lookup does not
succeed, there are callers interested in just this.
Signed-off-by: David Sterba <dsterba@suse.com>
Nodesize is used in kernel, the values are always equal. We have to keep
leafsize in headers, similarly the tree setting functions still take and
set leafsize, but it's effectively a no-op.
Signed-off-by: David Sterba <dsterba@suse.com>
At least 2 user from mail list reported btrfsck reported false alert of
"bad metadata [XXXX,YYYY) crossing stripe boundary".
While the reported number are all inside the same 64K boundary.
After some check, all the false alert have the same bytenr feature,
which can be divided by stripe size (64K).
The result seems to be initial 'max_size' can be 0, causing 'start' +
'max_size' - 1, to cross the stripe boundary.
Fix it by always update extent_record->cross_stripe when the
extent_record is updated, to avoid temporary false alert to be reported.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The need to specify the chunk root is not that common, we will reserve
the short option -c for later use.
Signed-off-by: David Sterba <dsterba@suse.com>
Add new btrfsck option, '--chunk-root', to specify chunk root bytenr.
And allow open_ctree_fs_info() function accept chunk_root_bytenr to
override the bytenr in superblock. This will be mainly used when chunk
tree corruption.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This reuses the existing code for checking the free space cache, we just
need to load the free space tree. While we do that, we check a couple of
invariants on the free space tree itself. This requires pulling in some
code from the kernel to exclude the super stripes.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If a file is linked from more than one directory and only one
of the links is corrupted, btrfs check dose not reset the nlink
properly. Actually it can go into infinite loop to link the broken file
into lost+found.
This patch fix two part of the code. The first one delay the freeing
valid (no error, found inode ref, directory index, and directory
item) backrefs. Freeing valid backrefs earier prevent reset_nlink() to
add back all valid links.
The second fix is obvious: passing `ref_type' to btrfs_add_link() is just
wrong. It should be `filetype' instead. The current code can break all valid
file links.
Signed-off-by: Naohiro Aota <naota@elisp.net>
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In process_extent_item(), it gives 'metadata' initial value 0, but for
non-skinny-metadata case, metadata extent can't be judged just from key
type and it forgot that case.
This causes a lot of false alert in non-skinny-metadata filesystem.
Fix it by set correct metadata value before calling add_extent_rec().
Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Since we have btrfs_close_all_devices() in btrfs's main entrance,
it is not necessary to call btrfs_close_all_devices() separately
in each sub-command.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The same code is executed when the condition "ret" is true or false,
because the code in the if-then branch and after the if statement is
identical.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The variable "err" is assigned to "ret" then "ret" gets overwritten by
check_extent_refs() before "ret" can be used. Reported by Coverity.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This patch is generated from a coccinelle semantic patch:
identifier t;
expression e;
statement s;
@@
-t = malloc(e);
+t = calloc(1, e);
(
if (!t) s
|
if (t == NULL) s
|
)
-memset(t, 0, e);
Signed-off-by: Silvio Fricke <silvio.fricke@gmail.com>
[squashed patches into one]
Signed-off-by: David Sterba <dsterba@suse.com>
There is a bug in btrfs-convert in 4.1.2, even we don't allow mixed
block group for converted image, btrfs-convert will still create image
with data and metadata inside one chunk.
And further more, the chunk type is still DATA or METADATA, not
DATA|METADATA (not mixed).
So add btrfsck check for it right now.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Added a missing newline to some error messages.
Also printf() was changed to fprintf(stderr) for error messages.
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Reviewed-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
mkfs creates more than one fs_devices in fs_uuids.
1: one is for file system being created
2: others are created in test_dev_for_mkfs in order to check mount point
test_dev_for_mkfs()-> ... -> btrfs_scan_one_device()
Current code only closes 1, and this patch also closes in case 2.
Similar problem exist in other tools, eg.::
cmd-check.c: the function is:
cmd_check()->check_mounted()-> ... -> btrfs_scan_one_device()
...
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
rec->crossing_stripes is not initialized in allocate place,
and have possibility causing wrong report for normal tree block.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We need not check path before btrfs_free_path() is called because
path is checked in btrfs_free_path().
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For a special case, discount file extent repair function will cause
infinite loop.
The case is, if the file loses all its extents, we won't have a hole
to fill, causing repair function doing nothing. Since the
I_ERR_DISCOUNT doesn't disappear, fsck will do an infinite loop.
For such case, just puch hole to fill the whole range to fix it.
Reported-by: Robert Munteanu <robert.munteanu@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If a file lost all its extents, fsck will unable to print out the hole.
Add an extra check to print out the hole range.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Kernel btrfs_map_block() function has a limitation that it can only
map BTRFS_STRIPE_LEN size.
That will cause scrub fails to scrub tree block which crosses strip
boundary, causing BUG_ON().
Normally, it's OK as metadata is always in metadata chunk and
BTRFS_STRIPE_LEN can always be divided by node/leaf size.
So without mixed block group, tree block won't cross stripe boundary.
But for mixed block group, especially for btrfs converted from ext4,
it's almost sure one or more tree blocks are not aligned with node size
and cross stripe boundary.
Causing bug with kernel scrub.
This patch will report the problem, although we don't have a good idea
how to fix it in user space until we add the ability to relocate tree
block in user space.
Also, kernel code should also be checked for such tree block alloc
problems.
Reported-by: Chris Murphy <lists@colorremedies.com>
Reported-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
