Btrfs-progs: fsck: don't free @seen cache until we finish searching

@seen cache is used to avoid iterating same block more than once, and
we can not free them until we have finished searching.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: fix possible memory leaks in run_next_block()

We still need free allocated cache memory in case error happens.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: reduce memory usage of extent record struct

Two changes:
	1.use bit filed for @found_rec
	2.u32 is enough to calculate duplicate extent number.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: fsck: fix wrong index in pick_next_pending()

Though all tree blocks have same size, we'd better use right
index here.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Modify the help string to keep consistent with man page.

Help string of "btrfs dev scan" is inconsistent with man page,
which lacks the fact that -d|--all-device is conflict with <device>.
This patch fixes the description

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: btrfs: remove dead code in handle_options

Just cleanup: remove useless return type, while loop and dead code.

Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Constify getters

Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: Make property work with -t option

# btrfs prop list -t f .
btrfs property list: too many arguments
...
# btrfs prop get -t f . label
btrfs property get: too many arguments
...
# btrfs prop set -t f . label abc
btrfs property set: too many arguments
...

Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: restore, for compressed extents don't read more bytes than needed

We need to read a number of bytes corresponding to the disk size of the file extent
item, and not to the number of bytes in the num_bytes field. Normally disk_size is
smaller than num_bytes (when using compression), except for files created with lzo
compression in a kernel older then the one which introduced the following change:

commit 59516f6017c589e7316418fda6128ba8f829a77f
Author: Stefan Agner <stefan@agner.ch>
Date:   Mon Jul 1 20:33:39 2013 +0200

    Btrfs: return -1 when lzo compression makes data bigger

    With this fix the lzo code behaves like the zlib code by returning an
    error
    code when compression does not help reduce the size of the file.
    This is currently not a bug since the compressed size is checked again
    in
    the calling method compress_file_range.

Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Btrfs-progs: update btrfs_file_extent_inline_len to match kernel version

The following kernel commit changed the definition of the inline function
btrfs_file_extent_inline_len():

    commit 514ac8ad8793a097c0c9d89202c642479d6dfa34
    Author: Chris Mason <clm@fb.com>
    Date:   Fri Jan 3 21:07:00 2014 -0800

    Btrfs: don't use ram_bytes for uncompressed inline items

    If we truncate an uncompressed inline item, ram_bytes isn't updated to reflect
    the new size.  The fixe uses the size directly from the item header when
    reading uncompressed inlines, and also fixes truncate to update the
    size as it goes.

Not having this new definition implies that the restore tool might misbehave when
restoring files with an inline extent that got truncated on a kernel older than
release 3.14.

Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
btrfs-progs: correct prompt of minimal num of devs for raid56

For btrfs,
Raid5 can't go below 2 devs, not 3;
Raid6 can't go below 3 devs, not 4.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
v3.14.1

Signed-off-by: Chris Mason <clm@fb.com>