btrfs-progs: fix many typos in documents

There are many trivial typos in Documentation/*.txt.
All of these use "exist status" to mean "exit status"
by mistake. I guess someone first made this mistake
and it has spread by copy-and-paste :-D

Signed-off-by: Naohiro Aota <naota@elisp.net>
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Properly cast to avoid compiler warnings, fixes FTBFS on alpha and ia64

Bug-Debian: http://bugs.debian.org/539433
Bug-Debian: http://bugs.debian.org/583768
Authors:
 Luca Bruno <lucab@debian.org>
 Alexander Kurtz <kurtz.alex@googlemail.com>
 Daniel Baumann <daniel.baumann@progress-technologies.net>

Signed-off-by: Dimitri John Ledkov <xnox@debian.org>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: update manpage with new option -f for btrfstune

The new option -f will force to do dangerous changes.
e.g. clear the seeding flag.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
[more text from 3db4c0a3d35dd5f8 changelog]
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: fix typo in subvol list usage

Signed-off-by: David Disseldorp <ddiss@suse.de>
[moved to new asciidoc]
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Add human readable incompat flags output for btrfs-show-super

Add human readable incompat flags output for btrfs-show-super,
now no longer needs to calculate the hex flags by hand.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: make BUG*() be more verbose

Currently these macros just tie to assert(), which gives us line number and such
but no backtrace so no actual context.  This patch adds support for spitting out
a backtrace so we can see how we got to the given assert.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
[backtrace_symbols_fd]
Signed-off-by: Naohiro Aota <naota@elisp.net>
[minor fixups]
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: don't assert when we have an invalid mapping

Asserting is no fun, we may be able to recover from this error in certain cases
(like btrfs-image and btrfsck).  Just do what the kernel does and spit out an
error and return that there is only 1 copy.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: let btrfs-image actually work on a balanced fs

We use the read extent buffer infrastructure to read the super block when we are
creating a btrfs-image.  This works out fine most of the time except when the fs
has been balanced, then it fails to map the super block.  So we could fix
btrfs-image to read in the super in a special way, but thats more code.  So
instead just check in the eb reading code if we are reading the super and then
don't bother mapping the block, just read the actual offset.  This fixed some
poor guy who was trying to btrfs-image his fs that had been balanced.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: add root to dirty list when fixing bad keys

A user reported a WARN_ON() when trying to run btrfsck --repair on his fs with
bad key ordering.  This was because the root that was broken wasn't part of the
transaction yet.  We do this open coded thing in a few other places in fsck, so
just make it a helper function and make sure all the places that need to call it
do call it.  With this patch he was able to run repair without it dying.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Check the csum tree node before go through the csum tree

[BUG]
Some fsfuzzed btrfs image will cause btrfsck segfault.

[REPRODUCER]
Run btrfsck on a csum tree block corrupted image.

[REASON]
check_csums() function call btrfs_search_slot() on csum_tree but doesn't
check whether the csum_tree contains a valid extent_buffer, which causes
the segfault.

[FIX]
Check the csum_root->node before any search.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: check all slots in leaves

There's an off by one error in btrfs_check_leaf, we should be going to nritems -
1, not nritems - 2, we were missing problems with items in the very last slot.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs progs v3.16.2

Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: deal with snapshot one by one when rebuilding extent tree

Previously, we deal with node block firstly and then leaf block which can
maximize readahead. However, to rebuild extent tree, we need deal with snapshot
one by one.

This patch makes us deal with snapshot one by one if we need rebuild extent
tree otherwise we drop into previous way.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: add ability to rebuild extent tree with snapshots

This patch makes us to rebuild a really corrupt extent tree with snapshots.
To implement this, we have to verify whether a block is FULL BACKREF.

This idea come from Josef Bacik:

1) We walk down the original tree, every eb we encounter has
btrfs_header_owner(eb) == root->objectid.  We add normal references
for this root (BTRFS_TREE_BLOCK_REF_KEY) for this root.  World peace
is achieved.

2) We walk down the snapshotted tree.  Say we didn't change anything
at all, it was just a clean snapshot and then boom.  So the
btrfs_header_owner(root->node) == root->objectid, so normal backref.
We walk down to the next level, where btrfs_header_owner(eb) !=
root->objectid, but the level above did, so we add normal refs for all
of these blocks.  We go down the next level, now our
btrfs_header_owner(parent) != root->objectid and
btrfs_header_owner(eb) != root->objectid.  This is where we need to
now go back and see if btrfs_header_owner(eb) currently has a ref on
eb.  If it does we are done, move on to the next block in this same
level, we don't have to go further down.

3) Harder case, we snapshotted and then changed things in the original
root.  Do the same thing as in step 2, but now we get down to
btrfs_header_owner(eb) != root->objectid && btrfs_header_owner(parent)
!= root->objectid.  We lookup the references we have for eb and notice
that btrfs_header_owner(eb) no longer refers to eb.  So now we must
set FULL_BACKREF on this extent reference and add a
SHARED_BLOCK_REF_KEY for this eb using the parent->start as the
offset.  And we need to keep walking down and doing the same thing
until we either hit level 0 or btrfs_header_owner(eb) has a ref on the
block.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs check: Pre-sort keys in a block while searching

When we think we might have a messed-up block with keys out of order
(e.g. during fsck), we still need to be able to find a key in the block.
To deal with this, we copy the keys, keeping track of where they came from
in the original node/leaf, sort them, and then do the binary search.

Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs check: Attempt to fix misordered keys with bitflips in them

If someone has had bad RAM which has been used to store a metadata block,
there's a chance that one or more of the keys has had a bit changed. The
block checksum doesn't help us here, because it's made on the bad data.

To fix this, if there's a block with a bad key order in it, we find out-of-
order keys by bracketing them between the good keys either side of them,
and then attempting to flip each bit of the key in turn.

If precisely one of those bitflips puts the broken key back into order
relative to its two neighbours, we probably have a fix for the bitflip,
and so we write it back to the FS.

This doesn't repair bitflipped keys at the start or end of a metadata
block, nor bitflips in any other data structure.

Signed-off-by: Hugo Mills <hugo@carfax.org.uk>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: disallow partial opening if critical roots corrupted

If btrfs tree root is corrupted, fsck will hit the following segmentation.

enabling repair mode
Check tree block failed, want=29376512, have=0
Check tree block failed, want=29376512, have=0
Check tree block failed, want=29376512, have=0
Check tree block failed, want=29376512, have=0
Check tree block failed, want=29376512, have=0
read block failed check_tree_block
Couldn't read tree root
Checking filesystem on /dev/sda9
UUID: 0e1a754d-04a5-4256-ae79-0f769751803e
Critical roots corrupted, unable to fsck the FS
Segmentation fault (core dumped)

In btrfs_setup_all_roots(), we could tolerate some trees(extent tree, csum tree)
corrupted, and we have did careful check inside that function, it will
return NULL if critial roots corrupt(for example tree root).

The problem is that we check @OPEN_CTREE_PARTIAL flag again after
calling btrfs_setup_all_roots() which will successfully return
@fs_info though critial roots corrupted.

Fix this problem by removing @OPEN_CTREE_PARTIAL flag check outsize
btrfs_setup_all_roots().

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: only allow partial opening under repair mode

The reason that we allow partial opening is that sometimes,
we may have some corrupted trees.(for example extent tree), for
fsck repair case, the broken tree may be rebuilt later.

So if users only want to do check but not repair anything, this
patch will make fsck return failure as soon as possible and
tell users that some critial roots have been corrupted.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: deal with corrupted csum root

If checksum root is corrupted, fsck will get segmentation. This
is because if we fail to load checksum root, root's node is NULL which
cause NULL pointer deferences later.

To fix this problem, we just did something like extent tree rebuilding.
Allocate a new one and clear uptodate flag. We will do sanity check
before fsck going on.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: repair: remove recowed entry from the to-recow list

If we attempt to repair a filesystem with metadata blocks that need
recowing, we'll get into an infinite loop repeatedly recowing the
first entry in the list, without ever removing it from the list.
Oops.  Fixed.

Signed-off-by: Alexandre Oliva <oliva@gnu.org>
Signed-off-by: David Sterba <dsterba@suse.cz>