Btrfs-progs: fix btrfsck improper prompt on dropping snapshots

Exec btrfsck on btrfs with snapshots that are under a dropping
progress will cause prompt on "ref mismatch".
However we do not want this kind of prompt, since an remount
operation will continue the dropping progress.
Here the prompt is nonsense.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: remove cmds-chunk.c

Commit "btrfs-progs: separate command and implementation of
chunk-recover code" moved contents of this file to chunk-recover.c but
failed to remove the file cmds-chunk.c

Reported-by: Mitch Harder <mitch.harder@sabayonlinux.org>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: make filesystem show by label work

with design revamp around filesystem show the fsid filter
by label wasn't planned. but apparently that seemed to be
necessary. this patch will fix it.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: allow --init-extent-tree to work when extent tree is borked

Unfortunately you can't run --init-extent-tree if you can't actually read the
extent root.  Fix this by allowing partial starts with no extent root and then
have fsck only check to see if the extent root is uptodate _after_ the check to
see if we are init'ing the extent tree.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: don't output baffling message when checking a fresh fs

As we know,  a new fs doesn't have space cache, so we set the cache generation
of the super block to be -1ULL, it is not equal to the fs generation. But the
check program didn't consider this case, and output the following message

  cache and super generation don't match, space cache will be invalidated

directly, it would be baffling the users. So we should avoid outputing such
message. This patch fixes this problem.

Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: fix loop device mount checks

When creating a fs on a loop device, mkfs checks whether the same file
is not already mounted, but a backing file of another loop dev does not
exist, mkfs fails. This fixes a bug during openSUSE installation.

Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: use /proc/self/mounts

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: make it static if function isn't called outside

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: try harder to make btrfs receive successfully

Steps to reproduce:
	# mkfs.btrfs -f <dev>
	# mount <dev> <mnt>
	# mkdir <mnt>/backup
	# btrfs sub create <mnt>/subv
	# btrfs sub snapshot -r <mnt>/subv <mnt>/snap1
	# btrfs sub snapshot -r <mnt>/subv <mnt>/snap2
	# btrfs send <mnt>/snap2 -p <mnt>/snap1 -f sent_file
	# btrfs receive -f sent_file <mnt>/backup

Above steps will make btrfs receive fails with "ERROR: can not find
parent subvolume", this is because we try to find parent subvolume by
RECEIVED_SUBVOL_KEY,and it will return ENOENT if parent snapshot has not
been sent or it has been deleted. Actually, we can try harder to find
whether parent subvolume exists by searching uuid key.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: let get_label return the label instead of printing it

get_label prints the label at the moment. Change this so that
the label is returned and printing is done by the caller.

Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: define BTRFS_UUID_UNPARSE_SIZE for uuid unparse buf size

we use 37 as the allocation size to hold the uuid_unparse, here
it defines BTRFS_UUID_UNPARSE_SIZE for the same.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: Make btrfs_header_chunk_tree_uuid() return unsigned long

Internally, btrfs_header_chunk_tree_uuid() calculates an unsigned
long, but casts it to a pointer, while all callers cast it to unsigned
long again.

From btrfs commit b308bc2f05a86e728bd035e21a4974acd05f4d1e

Signed-off-by: Ross Kirk <ross.kirk@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: chunk-recover: use right size when allocating chunk root node

When allocating chunk root node, we should use nodesize rather than sectorsize,
this will casue regression when making other nodesize choice.(for example 16k size now)

Reported-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: fix the mismatch of extent buffer's space

Now we set @refs to 2 on creating a new extent buffer, meanwhile we
allocate the needed free space, but we don't give enough free_extent_buffer()
to reduce the eb's references to zero so that the eb can finally be freed,
so the problem is we has decrease the referene count of backrefs to zero, which
ends up releasing the space occupied by the eb, and this space can be allocated
again for something else(another eb or disk), usually a crash(core dump) will
occur, I've hit a crash in rb_insert() because another eb re-use the space while
the original one is floating around.

We should do the same thing as the kernel code does, it's necessary to initialize
@refs to 1 instead of 2, this helps us get rid of the above problem.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: call endmntent in btrfs_scan_kernel

btrfs_scan_kernel() does a getmntent() but never releases the
filedescriptor it gets back from that.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64711

Reported-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: use mntent functions in find_mount_root

getmntent should be used in context of *mntent functions, though
fopen/fclose works.

Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Btrfs-progs: chunk-recover: add new flag to prepare recovering for ordered data chunk

When reading block groups we will searching it's corresponding chunk, however, at this
time, some chunks has not been built(data chunks raid0/raid10/raid56), don't bug_on here,
we will try to rebuild these chunks later.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: skip chunk recover works when check chunks successfully

If no chunks need to be recovered, skip the recover works,
meanwhile the user won't be annoyed by the "ask_user".

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: add chunk-recover raid0/5/6 data stripes rebuild routine

Decide the raid0/5/6 data stripes' order using checksums.
For one chunk, fetch each 64k logical stripe
	1. search its checksum in the csum tree
	2. read the physical stripe data on each device
	3. calc the data checksums
	4. if one checksum matches the value from the csum tree,
	   then the logical stripe resides in that device,
	   the stripe order index can be calculated.
	5. if more than one checksums match,
	   then use the successive csum in the tree to compare again.
	6. if equal stripes are encountered, just fetch next stripe.
	7. if some devices' order are still not decided, then they
	   can not be recovered.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
btrfs-progs: scan devices in parallel for chunk-recover

Originally, multi devices are scanned one by one;
Now, one thread is used per device to scan.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>