Probably with a new gcc (7.1.1) I started to see asan/ubsan link failures.
Fixed by explicitly linking the libraries.
Signed-off-by: David Sterba <dsterba@suse.com>
Except libbtrfs.so object, all other tools compile fine. The error is:
ld: send-stream.o: relocation R_X86_64_PC32 against symbol
`stderr@@GLIBC_2.2.5' can not be used when making a shared object;
recompile with -fPIC
Compiling with -fPIC fixes the problem.
Signed-off-by: David Sterba <dsterba@suse.com>
The variable LD_FLAGS does not exist and the flags are not used, we need
to use the newly added internal debugging linker flags.
Signed-off-by: David Sterba <dsterba@suse.com>
The call to btrfs_read_block_groups could loop if the metadata are
damaged (reported eg. for an unaligned block), due to lack of error
handling. We have to check for restored images or currently created
filesystems, that do not contain the blockgroups.
Can be reproduced by fuzzed image bko-155551.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=155551
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Tree blocks are always nodesize. As readahead is only an optimization,
exact size is not required and is only advisory.
Signed-off-by: David Sterba <dsterba@suse.com>
Metadata blocks are always nodesize. When reading the
superblock::sys_array, the actual size of data is fixed to 4k and
smaller than nodesize, but otherwise everything works as before.
Signed-off-by: David Sterba <dsterba@suse.com>
The tree blocks are supposed to be always of nodesize. Before the
parameter has been dropped, it was unlikely but possible to pass a
misaligned value.
Signed-off-by: David Sterba <dsterba@suse.com>
Patch from Marcus Meissner <meissner@suse.com>. The CFLAGS are passed to
the linker and mix up the compilation and linker flags for PIE support.
Signed-off-by: David Sterba <dsterba@suse.com>
Many of the test cases for convert apply regardless of what the source
file system is and using ext4 is sufficient. I've included several
test cases that are reiserfs-specific.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
[ patch split from the previous one, minor cleanups in common.convert ]
Signed-off-by: David Sterba <dsterba@suse.com>
This patch adds support to convert reiserfs file systems in-place to btrfs.
It will convert extended attribute files to btrfs extended attributes,
translate ACLs, coalesce tails that consist of multiple items into one item,
and convert tails that are too big into indirect files.
This requires that libreiserfscore 3.6.27 be available.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There multiple places where we use well-known sizes - 1,8,16,32 megabytes. We
also have them defined as constants in the sizes.h header. So let's use them.
No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For code maintainability and scalability,
replace hardcoded constant with a meaningful enum.
Signed-off-by: Gu Jinxiang <gujx@cn.fujitsu.com>
[ add MKFS_ prefix ]
Signed-off-by: David Sterba <dsterba@suse.com>
type -p returns an empty string for nonexistent commands, but the -f
test on an empty string does not behave the same on all shells. To be
safe, use the quoted value.
Signed-off-by: David Sterba <dsterba@suse.com>
Usage info of "btrfs check" shows "-Q|--qgroup-report" (and first patch
enables -Q), but the document only shows "--qgroup-report".
Therefore add -Q to the doc.
Signed-off-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
I found some btrfs commands options are not working because of
inappropriate getopt_long() setting.
This fixes "btrfs check -Q/-E"
Signed-off-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This function has an extra argument and can get forgotten, add a sanity
check so the bad usage can be caught during development.
Signed-off-by: David Sterba <dsterba@suse.com>
In this test case, all name in dir_item, dir_index, inode_ref
are corrupted to another one.
btrfs check should report errors about the corrupted dir_item but
btrfs can't repair the case now.
Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Although lowmem mode can detect name and hash mismatch in dir_item,
it's done by checking inode_ref to expose such problem.
This patch will enhance dir_item check, by also comparing name and
hash when checking dir_items.
Reported-by: Filippe LeMarchand <gasinvein@gmail.com>
Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
In original mode, we don't check if the name in dir_item matches the
hash in key.offset.
In the following case, original mode will report nothing wrong while
lowmem mode will detect the name and hash mismatch.
------
item 72 key (79177 DIR_ITEM 54846528) itemoff 12380 itemsize 88
location key (4222342 INODE_ITEM 0) type FILE
transid 170929 data_len 0 name_len 14
name: deprecated.sxt
location key (13590433 INODE_ITEM 0) type FILE
transid 796448 data_len 0 name_len 14
name: deprecated.txt
------
In above case, hash of "deprecated.txt" matches with 54846528,
while hash of "deprecated.sxt" should be 2008317993.
Reported-by: Filippe LeMarchand <gasinvein@gmail.com>
Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The dd in convert-tests/008-readonly-image is expected to fail, so
there being a typo in the file name has gone unnoticed.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When we are looking for extents in migrate_one_reserved_range, it's likely
that there will be multiple extents that fall into the 0-1MB range.
If lookup_cache_extent is called with a range that covers multiple cache
entries, it will return the first entry it encounters while searching
from the top of the tree that happens to fall in that range. That
means that we can end up skipping regions within that range, resulting
in a file system image that can't be rolled back since it wasn't
all migrated properly.
This is reproducible using convert-tests/008-readonly-image. There was
a range from 0-160kB, but the only entry that was returned began at
~ 280kB.
The fix is to use search_cache_extent to iterate through multiple regions
within that range.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
There are two printfs with missing newlines that end up making the
output wonky.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 522ef705e3 (btrfs-progs: convert: Introduce function to calculate
the available space) changed how we handle migrating file data so that
we never have btrfs space associated with the reserved ranges. This
works pretty well and when we iterate over the file blocks, the
associations are redirected to the migrated locations.
This commit missed the case in block_iterate_proc where we just check
for intersection with a superblock location before looking up a block
group. intersect_with_sb checks to see if the range intersects with
a stripe containing a superblock but, in fact, we've reserved the
full 0-1MB range at the start of the disk. So a file block located
at e.g. 160kB will fall in the reserved region but won't be excepted
in block_iterate_block. We ultimately hit a BUG_ON when we fail
to look up the block group for that location.
This is reproducible using convert-tests/003-ext4-basic.
The fix is to have intersect_with_sb and block_iterate_proc understand
the full size of the reserved ranges. Since we use the range to
determine the boundary for the block iterator, let's just return the
boundary. 0 isn't a valid boundary and means that we proceed normally
with block group lookup.
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Replace in-place exit with a common exit block in the main function.
Signed-off-by: Gu Jinxiang <gujx@cn.fujitsu.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Parameter fd is not used in function make_image and traverse_directory
of mkfs. Delete it.
Signed-off-by: Gu Jinxiang <gujx@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For btrfs inspect-internal dump-tree, if we use "-b" parameter to show
specified tree block, then we don't really need extra tree roots.
Only chunk root is needed to build up the whole chunk mapping so we can
read tree blocks.
This patch will add __OPEN_CTREE_RETURN_CHUNK_ROOT flag when show
speicifed tree block.
So even root tree is corrupted, we can still use inspect-internal
dump-tree to do some debugging.
Reported-by: Zirconium Hacker <jared.e.vb@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Code block of kernel backtrace lacks leading change line, causing the
following man page result:
------
One can determine whether zero-log is needed according to the
kernel backtrace:
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? walk_log_tree+0x9c/0x19d [btrfs]
? btrfs_read_fs_root_no_radix+0x169/0x1a1 [btrfs]
? btrfs_recover_log_trees+0x195/0x29c [btrfs]
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? btree_read_extent_buffer_pages+0x76/0xbc [btrfs]
? open_ctree+0xff6/0x132c [btrfs]
+ If the errors are like above, then zero-log should be used to clear
the log and the filesystem may be mounted normally again. The keywords
------
Not only "+" is rendered as is, but also wrong indent.
Fix it by adding change line before code block.
Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Different C compilers have different default language standard.
This sometimes causes problem on different system.
For distribution like CentOS/RHEL7, its gcc is still 4.8 and will report
error for c90 style declaration, while most developers are using newer
gcc which will just ignore it.
This makes us hard to detect such language standard problem.
This patch will specify standard to gnu90 explicitly to avoid such problem.
Gnu90 is a good mix of c90 while provide a lot of useful gnu extension,
and is supported by all modern gcc and clang.
Reported-by: Marco Lorenzo Crociani <marcoc@prismatelecomtesting.com>
Signed-off-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The contents of tables.c hasn't changed for more than 15 years, we don't
expect any changes to current contents. New tables might be still added,
in that case the file should be regenerated using the included mktables
tool and updated.
Signed-off-by: David Sterba <dsterba@suse.com>
