Btrfs-progs: skip open devices which is missing

A device can be added to the device list without getting a name, so we may
access to illegal addresses while opening devices with their name.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix misuse of skinny metadata in btrfs-image

As for skinny metadata, key.offset stores levels rather than extent length.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix reference check for roots in btrfsck

I noticed that I was getting these errors on a bigger file system with more
snapshots that had been removed.  This check is bogus since we won't inc
rec->found_ref if we don't find a REF_KEY _and_ a DIR_ITEM, so we only have to
worry about there being no references to a root if it actually has a root item.
If it doesn't then it's just referenced by things that will go no where anyway.
With this patch fsck no longer incorrectly complains about this file system
image I have.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix incorrect root backref errors in fsck

A user reported that fsck was complaining about unresolved refs for some
snapshots.  You can reproduce this by doing

mkfs.btrfs /dev/sdb
mount /dev/sdb /mnt
btrfs subvol snap /mnt/ /mnt/a
btrfs subvol snap /mnt/ /mnt/b
btrfs subvol del /mnt/a
umount /mnt
btrfsck /dev/sdb

and you'd get this

unresolved ref root 258 dir 256 index 2 namelen 1 name a error 600

because snapshot b has a dir item that points to a.  Except we encode in our
root ref the dirid of the ref holder, and if it doesn't match we just give it
back a empty directory since we can't hardlink directories.  This makes the
check in btrfsck bogus, when we delete a we remove the ref key for it so any
lookups into /mnt/b/a will just give a blank directory as it's supposed to.  Fix
this by only saying the backref is reachable if there is both a DIR_ITEM and a
REF_KEY for the given root.  With this patch I no longer see errors when running
this reproducer.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix fsck dealing with finding backrefs first

There is a problem where if we find a backref extent record first that doesn't
match a extent item we will delete some of the duplicates but not others.  In
order to deal with this we need to make sure we only pay attention to duplicates
that actually have duplicate extent items.  If a extent_rec has a duplicate but
the record itself doesn't have an associated extent item we promote the
duplicate to the extent record and just discard the original extent_rec since it
was just added by the backref.  We copy the backref onto the promoted extent
record and then continue processing.  This allowed me to fix a file system that
previously was not able to be fixed by fsck.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix the allocator

The allocator looks for these hints when moving on to another block group which
will make it reset which block group it looks at, when we've already searched
that block group and didn't find any space to allocate, we need to fix this by
just letting the allocator make the determination if the block group is good
enough.  This also fixes a problem where if we couldn't find space in the block
group we were given we'd just error out instead of moving on to the next block
group.  Previously I couldn't fix some file systems that were relatively full,
but with this patch I can now run fsck on them with no allocation errors.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix free space cache checks

This fixes two bugs with the free space cache checker.  First is we apparently
always use root->sectorsize for our unit in the kernel so we have to do that in
progs otherwise bitmaps turn out to not look right if we have leafsize !=
sectorsize.  The second is a small issue if we had skinny metadata extents set,
we wouldn't advance last properly because we unconditionally use key.offset
instead of root->leafsize.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: add --init-extent-tree to btrfsck

In some cases the extent tree can just be so gone there is no point in trying to
figure out how to put it back together.  So add a --init-extent-tree mode which
will zero out the extent tree and then re-add extents for all of the blocks we
find.  This will also undo any balance that was going on at the time of the
crash, this is needed because the reloc tree seems to confuse fsck at the
moment.  With this patch I can put back together a users file system that was
completely gone.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: add a newline to a free space cache message

Left out a newline in the generation check printf.

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: make image restore with the original device offsets

I noticed a slight problem with btrfs-image, since it was building a chunk tree
by setting the physical offset of the stripes to the same as the logical offset
it created this problem where the super block was now mapped into the file
system differently than it was before.  This isn't a huge deal except that we
also carry along the free space cache with us, which is setup with the idea that
super at physical X is at logical Y.  So this would make the free space checker
in fsck freak out because it would see that the cache says that the super block
is free space, and that the area where it thought the super block was located is
in fact used.  In the mount case we'd end up overwriting real metadata with
backup super blocks.  So we need to maintain the physical offsets in our
stripes.  This is a huge pain because we store the logical bytenrs of all of our
metadata.  This patch scans the entire image looking for chunk tree blocks and
builds an in memory chunk tree so we can write logical blocks to their physical
offsets.  With this patch we no longer have the problems I described above.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: pass properly formated key to read_fs_root

We have a BUG_ON() in read_fs_root that expects key->offset == (u64)-1.  Restore
will just pass in the location it reads out of the inode if it has a subvol
reference and pass that in, which doesn't have offset == (u64)-1, so it causes
restore blow up.  This was reported in bugzilla and this patch fixed the
problem.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: make fsck fix certain file extent inconsistencies

The tree log bug I introduced could create inconsistent file extent entries in
the file system tree and in some worst cases even create multiple extent entries
for the same entry.  To fix this we need to do a few things

1) Keep track of extent items that overlap and then pick the one that covers the
largest area and delete the rest of the items.

2) Keep track of file extent items that land in extent items but don't match
disk_bytenr/disk_num_bytes exactly.  Once we find these we need to figure out
who is the right ref and then fix all of the other refs to agree.

Each of these cases require a complete rescan of all of the extents, so
unfortunately if you hit this particular problem the fsck is going to take quite
a while since it will likely rescan all the trees 2 or 3 times.  With this patch
the broken file system a user sent me is fixed and a broken file system that was
created by my reproducer is also fixed.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-image: add the ability to santize file names when making an image

We've had a few users who wouldn't (or couldn't) provide us btrfs-images because
we maintain the file names when making an image.  So introduce a sanitize
option.  There are two uses, one that is fast and the other that is dog slow.
The fast way just generates garbage that's equal in length to the original name.
The slow way will try and find a crc32c collision for the file name that is also
the same length.  Finding a crc32c collision for the file name "btrfs-progs" on
my box without CPU crc32c support takes a little more than 3 minutes, and a
little less than 2 minutes for my box that has CPU crc32c support, so it's a
lengthy and CPU intensive process.

The idea is that we use -s for most cases, and then only use -ss when we need
the file system tree to be somewhat sane.  I could probably do a better job
about finding collisions, but I'll have to revist that later.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: add the ability to find mismmatching backrefs

An unfortunate side effect to my fsync bug means that anybody who didn't hit the
BUG_ON() during tree log replay would have ended up with a corrupted file
system.  Currently our fsck does not catch this because it just looks for
bytenrs for backrefs, it doesn't look at the num_bytes at all.  So this patch
makes us keep track of how big the backrefs are, since their disk_num_bytes
_have_ to match the number of bytes for the actual extent item.  With this patch
fsck now finds problems with a file system it previously thought was ok.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: sanity check the number of items in a leaf V2

I hit this while working on fsck, I got some weird corruption where the number
of items was way higher than what would fit in a leaf, which would make things
blow up.  This fixes the problem by catching it and returning an error so we
gracefully exit instead of segfaulting.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fix compile warnings in i386 machine

See the warnings below:

   [CC]     btrfs-list.o
btrfs-list.c: In function 'filter_by_parent':
btrfs-list.c:1183:34: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
     [CC]     cmds-subvolume.o
cmds-subvolume.c: In function 'cmd_subvol_show':
cmds-subvolume.c:917:5: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
     [CC]     cmds-restore.o
cmds-restore.c: In function 'decompress_lzo':
cmds-restore.c:116:10: warning: passing argument 4 of 'lzo1x_decompress_safe'
from incompatible pointer type [enabled by default]
In file included from cmds-restore.c:31:0:
/usr/include/lzo/lzo1x.h:77:1: note: expected 'lzo_uint *' but argument is of
type 'size_t *'

Reported-by: Russell Coker <russell@coker.com.au>
Signed-off-by: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

btrfs-progs: fix typecast when printing csum value

Only the first byte of the wanted csum is printed:

checksum verify failed on 65536 found DA97CF61 wanted 6B
checksum verify failed on 65536 found DA97CF61 wanted 6BC3870D

Also add leading zeros to the format.

Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: fixup: add flags to struct btrfs_ioctl_quota_rescan_args

The patch set previously sent was sent together with the kernel part, but
was not updated as I added some reserved bytes to the ioctl struct for
future compatibility. This fixes struct btrfs_ioctl_quota_rescan_args.

Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

Btrfs-progs: init free space ctl with proper unit

btrfsck was blowing up when checking the free space cache when we ran xfstests
with -l 64k.  That is because I was init'ing the free space ctl to whatever the
leafsize was, which isn't right for data block groups.  With this patch btrfsck
no longer complains.  This also fixes a tiny little typo in free-space-cache.c I
noticed while figuring this problem out.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

btrfs-image: fix reading the super block on big metadata blocks

btrfs-image is assuming that every metadata block is the same size.  The
super is a special snowflake though.  It's 4K even on 64K filesystems.

Signed-off-by: Chris Mason <chris.mason@fusionio.com>

btrfs-progs: mkfs seg fault for wrong free

With commit
        87c09f7 Btrfs-progs: fix memory leaks on cleanup

mkfs on multiple dev is ending with segfault at
close_all_devices() during kfree(device->name)

because mkfs calls btrfs_add_to_fsid, which does not initialize
name when dev is added to the list.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

btrfs-progs: Add default rules to Makefile

Add a default rule for any btrfs-$FOO or btrfs-$FOO.static
target, allowing it to be built from btrfs-$FOO.c along with
all the normal userspace objects.

This gets rid of a lot of the cut and pasted rules for
each individual command, and as an added bonus makes it
easy to build any btrfs-$FOO statically as well, i.e.

  # make btrfs-convert.static

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: standardize tool source filenames

For any btrfs-$FOO executable, rename the main source file from
$FOO.c to to btrfs-$FOO.c

This makes it slightly more obvious what's building what,
and allows us to write a default rule in the Makefile for
these tools.

(also add btrfs-calc-size to the list of objects to remove
on make clean)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

Btrfs-progs: add function to map subvol ID to path

Several tools like btrfs-send and btrfs-receive need to map a
subvolume ID to a filesystem path. The so far existing methods
in btrfs-list.c cause a horrible effort when performing this
operation (and the effort is dependent on the number of
existing subvolumes with quadratic effort). This commit adds a
function that is able to map a subvolume ID to a filesystem path
with an effort that is independent of the number of existing
subvolumes.

In addition to this function, a command line frontend is added as well:
btrfs inspect-internal subvolid-resolve <subvolid> <path>

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: in btrfs-debug-tree, print -1 in key for (u64)-1

For the objectid and offset field of a key, print -1 instead of the
decimal representation of 0xffffffffffffffff. At least for me it is
more readable like this.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: btrfs-send: free used memory and close fds

Not important at all since exit() is called afterwards and this is
not part of the library. It just makes valgrind happy and thus
allows to search for real flaws.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: btrfs-crc: support specifying checksum in hex

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

btrfs-progs: update generation_v2 in btrfs_update_root

This addresses the same issue as did:

2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck

but rather than optionally updating generation_v2 based
on the size of the existing item, increase the size of the
item as needed, and unconditionally set generation_v2.
This matches the kernel code, and keeping things in sync is a
Good Thing.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: set generation_v2 any time we write a new root

With this integration branch commit in place:

2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck

I started seeing generation mismatch messages from the kernel
at mount time, after a fresh mkfs(!):

  btrfs: mismatching generation and generation_v2 found in root item...

This is because the code which emits the warning does not do so if
there is a mismatch but generation_v2 is 0; the above commit began
setting generation_v2 to something non-zero, so the warning was emitted.

The reason there is a mismatch at all is because mkfs.btrfs calls
create_data_reloc_tree(), which copies a root, and then calls
btrfs_set_root_generation(), bumping the original copied generation.
But nothing updated generation_v2 to match on the way to disk.

Fix this by updating generation_v2 in btrfs_insert_root(),
as is done in the kernel.

This is safe because it's a new root created by userspace, so
the btrfs_root_item is guaranteed to be big enough to contain
generation_v2.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: fix send-test build

btrfs_read_and_process_send_stream() recently changed its prototype;
this gets it building again.  0 means "do not honor the <end cmd>"
which was the previous default, before

2bfac02 Btrfs-progs: btrfs-receive optionally honors the end-cmd

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

Btrfs-progs: quota rescan

This adds the quota rescan command to be used if qgroup tracking should get
out of sync. Can also be used to query the status of a running rescan
operation.

Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>

Btrfs-progs: make restore deal with really broken file systems

All we need for restore to work is the chunk root, the tree root and the fs root
we want to restore from.  So to do this we need to make a few adjustments

1) Make open_ctree_fs_info fail completely if it can't read the chunk tree.
There is no sense in continuing if we can't read the chunk tree since we won't
be able to translate logical to physical blocks.

2) Use open_ctree_fs_info in restore, and if we didn't load a tree root or
fs root go ahead and try to set those up manually ourselves.

This is related to work I did last year on restore, but it uses the
open_ctree_fs_info instead of my open coded open_ctree.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: fix csum check when extent lands on block group

I was running fsync() tests and noticed that occasionally I was getting a bunch
of errors from fsck complaining about csums not having corresponding extents.
Thankfully after a few days of debugging this it turned out to be a bug with
fsck.  The csums were for an extent that started at the same offset as a block
group, and were offset within the extent.  So the search put us out at the block
group item and we just walked forward from there, never finding the actual
extent.  This is because the block group item key is higher than the extent item
key, so it comes first.  In order to fix this we need to check and see if we
landed on a block group item and take another step backwards to make sure we end
up at the extent item.  With this patch my reproducer no longer finds csums that
don't have matching extent records.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: record errno for ioctl DEFRAG_RANGE

In order to sparse exact error message, we need to record errno here.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>

btrfs-progs: delete unused function btrfs_read_super_device

Signed-off-by: Anand Jain <anand.jain@oracle.com>

Btrfs-progs: add csum tree checks to btrfsck

Looking at a recent user problem I noticed there are weird cases we could
possibly be leaving csums in place for an extent we've free'd.  I don't think
this can happen unless the extent tree is also corrupt, but just in case I'm
adding sanity checks to btrfsck.  This way we will catch this if it happens
normally since xfstests runs btrfsck between each run.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: fix segfault in fsck if the chunk tree is bogus

I made open_ctree fail if the chunk tree couldn't be open, which means that fsck
now segfaults if it can't open the chunk tree.  So fix fsck to check the fs_info
we get back from open_ctree_fsinfo to make sure it's valid and exit if it's not
instead of segfaulting.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: add an option to btrfs-image to walk the trees

When working with a user with a broken file system I noticed I wasn't able to
read some of the blocks properly from the restored image.  This is because his
extent tree was corrupt and was missing references to some of the blocks, which
means they weren't copied into the image when he generated it.  So add a -w
option which will walk all of the trees manually and copy them into the image.
This way we can run fsck against a complete file system image and fix any bugs
in fsck.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

btrfs-progs: use clearer var names in is_ssd()

is_ssd() uses nondescript variable names; path - to what?
disk - it's a dev_t not a disk name, unlike dev, which is
a name not a dev_t!

Rename some vars to make things hopefully clearer:

 wholedisk - the name of the node for the entire disk
 devno - the dev_t of the device we're mkfs'ing
 sysfs_path - the path in sysfs we ultimately check

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: replace blkid_probe_get_wholedisk_devno

blkid_probe_get_wholedisk_devno() isn't available in some older
versions of libblkid.  It was used to work around an old
bug in blkid_devno_to_wholedisk(), but that has been fixed since
5cd0823 libblkid: fix blkid_devno_to_wholedisk(), present in
util-linux 2.17 and beyond.

If we happen to be missing that fix, the worst that happens is
that we'd fail to detect that a device is an ssd; the upside is
that this code compiles on older systems.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: Fix the receive code pathing

The receive code was not distinguishing properly between the mount root
and the directory to create the received subvolume in.
Also make sure the find_mount_root reports an error if it cannot find
a match at all.

Reported-by: Robert Buhren <robert@robertbuhren.de>
Reported-by: Rory Campbell-Lange <rory@campbell-lange.net>
Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
Signed-off-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: allow to receive to relative directories

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: remove some unused code

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: Fix that BTRFS_FSID_SIZE is used instead of BTRFS_UUID_SIZE

Both are 16 but it's wrong anyway to use FSID_SIZE for UUIDs.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: don't allocate one byte too much each time

str1 + '/' + str2 + '\0' requires a buffer with the size
strlen(str1) + strlen(str2) + 2 bytes.

str1 + '/' + str2 + '/' + str3 + '\0' requires a buffer with the size
strlen(str1) + strlen(str2) + strlen(str3) + 3 bytes.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: btrfs-receive optionally honors the end-cmd

A new option is added to btrfs-receive to change the behavior when
an <end cmd> is received in the Btrfs send stream.

The traditional behavior (which still is the default) is to continue
to read the stream until an EOF condition is encountered. If an
<end cmd> is received, afterwards either an EOF or a new
<stream header> is expected.

The new behavior (if the -e option is set on the command line) is
to terminate after an <end cmd> is read without the need for an EOF.
This allows the stream (e.g. a single TCP stream) to carry additional
data or even multiple Btrfs send streams.

Old btrfs-send tools used to encode multiple snapshots like this
(with 2 snapshots in this example):
<stream header> + <sequence of commands> + <end cmd> +
<stream header> + <sequence of commands> + <end cmd> + EOF

If the new -e option is set, the expected format is like this:
<stream header> + <sequence of commands> +
                  <sequence of commands> + <end cmd>

The btrfs-send tool is changed in a seperate commit to always use
the new format, i.e. to send an <end cmd> only at the end.

Note that the currently existing receivers treat <end cmd> only as
an indication that a new <stream header> is following. This means,
you can just skip the sequence <end cmd> <stream header> without
loosing compatibility. As long as an EOF is following, the currently
existing receivers handle the new format (if the two new flags are
used) exactly as the old one.

The goal of changing the semantic of <end cmd> is to be able to use
a single stream (one TCP connection) to multiplex a request/response
handshake plus Btrfs send streams, all in the same stream. In this
case you cannot evaluate an EOF condition as an end of the Btrfs send
stream. You need something else, and the <end cmd> is just perfect
for this purpose.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: fix bug in find_root_gen

A copy & paste error.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: small parent_subvol cleanup for cmds-receive.c

parent_subvol is local to process_snapshot() and not needed outside.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: Set the root-id for received subvols in btrfs receive

When an entry was added to the subvol search tree, the root_id was
always 0 (not set at all) and therefore only the first one was
added, all the others had been ignored. This commit sets the root_id
before the entry is added.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: btrfs-receive: different levels (amount) of debug output

There used to be 2 levels of verbose output, now there are 3:
- None at all (no -v option given).
- Some information about received snapshots / subvolumes (-v option).
- Each received command is printed (-vv option).

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: free memory and close file descriptor in btrfs receive

Nothing really important since this is not part of the library and
at the end exit() is called.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: cleanup subvol_uuid_search memory in btrfs send/receive

Call the cleanup function that was introduced with the other commit.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: add a function to free subvol_uuid_search memory

There was no way to free the memory that was used for the
subvol_uuid_search functions. Since this is part of the libbtrfs,
add such a cleanup function.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: fix a small memory leak in btrfs-list.c

valgrind found this very obvious issue.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: close file descriptor in cmds-send.c

valgrind found this very obvious issue.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: ignore subvols above BTRFS_LAST_FREE_OBJECTID

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

btrfs-progs: add quota-related info to usage messages

Extending usage messages with some info on the quota functionality:
     - The -i option of "subvol create" and "subvol snapshot" was not
documented
     - The -c option of "qgroup limit" is the default option
     - The "qouta rescan" command is not yet implemented, while it should be
       executed after enabling quota on a non-empty filesystem.

Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>

Btrfs-progs: add a free space cache checker to fsck V2

In trying to track down a weird tree log problem I wanted to make sure that the
free space cache was actually valid, which we currently have no way of doing.
So this patch adds a bunch of support for the free space cache code and then a
checker to fsck.  Basically we go through and if we can actually load the free
space cache then we will walk the extent tree and verify that the free space
cache exactly matches what is in the extent tree.  Hopefully this will always be
correct, the only time it wouldn't is if the extent tree is corrupt or we have
some sort of awful bug in the free space cache.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

btrfs-progs: do not enable extended refs in mkfs by default

This extref feature (lifting the single file hardlink limitation) is new
and not backward compatible with older kernels that are still in wide
use.

For now, use btrfstune to enable the feature, in the future it will be
possible to turn it on within mkfs by -O option.

Signed-off-by: David Sterba <dsterba@suse.cz>

btrfs-progs: revert skinny extents changes from mkfs

We are going to unify enabling filesystem features via option -O.
For now, use btrfstune to enable the features.

Signed-off-by: David Sterba <dsterba@suse.cz>

Btrfs-progs: add skinny metadata support to progs V3

This fixes up the progs to properly deal with skinny metadata.  This adds the -x
option to mkfs and btrfstune for enabling the skinny metadata option.  This also
makes changes to fsck so it can properly deal with the skinny metadata entries.
Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

btrfs-progs: re-add send-test

send-test.c links against libbtrfs and uses the send functionality provided
to decode and print a send stream to the console.

66819df "btrfs-progs: add send-test" contained this file when
submitted, but somehow got lost on commit.

[sandeen@redhat.com: Resurrect lost send-test.c from original commit]

Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: btrfs-select-super output is confusing when it fails

Trivial patch:
./btrfs-progs/btrfs-select-super -s 0 /dev/sdc
using SB copy 0, bytenr 65536
No valid Btrfs found on /dev/sdc
Open ctree failed

The line 'using..' is confusing which gives an
indication that command is successful

This patch will avoid that when command fails

Signed-off-by: Anand Jain <anand.jain@oracle.com>

btrfs-progs: mkfs should first check all disks before writing to a disk

In the cases where one of the disk is not suitable for
btrfs, then we would fail the mkfs, however we determine
that after we have written btrfs to the preceding disks.
At this time if user changes mind for not to use btrfs
will left with no choice.

So this patch will check if all the provided disks are
suitable for the btrfs at once before proceeding to
create btrfs on a disk.

Further this patch also removed duplicate code to check
device suitability for the btrfs.

Next, there is an existing bug about the -r mkfs option,
which this patch would carry forward most of it.
Ref:
[PATCH 2/2, RFC] btrfs-progs: overhaul mkfs.btrfs -r option

Signed-off-by: Anand Jain <anand.jain@oracle.com>
to merg prev

Signed-off-by: Anand Jain <anand.jain@oracle.com>

btrfs-progs: no pending balance is not an error

Having no balance running/ paused/completed is a normal
situation, so the current output message should be positive
with return val zero.

Signed-off-by: Anand Jain <anand.jain@oracle.com>

btrfs-progs: fix btrfs scrub start help

a very trivial fix

Signed-off-by: Anand Jain <anand.jain@oracle.com>

btrfs-progs: delete unused function get_mountpt

and get_btrfs_mount has replaced it

Signed-off-by: Anand Jain <anand.jain@oracle.com>

Btrfs-progs: Use /proc/mounts instead of /etc/mtab

/etc/mtab is not working correctly in situations where multiple
mount namespaces are used. Use /proc/mounts instead like the
rest of the code is doing it.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

Btrfs-progs: add btrfs-crc tool

This tool can be used to compute btrfs' style crc32c checksums for filenames
as done by the kernel. Additionally, there is -c mode to do a brute force
search for file names with a given checksum.

Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>

btrfs-progs: add missing qgroup synopsis in btrfs

Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>

btrfs-progs: fix one bracket issue in mkfs.btrfs manpage

  In "[ \fB\-f\fP\fI ]", the "\fI" will result in the front half "["of
"[ -f ]" doesn't the back half "]"; When you issue the command
"man mkfs.btrfs", you will see the difference.

Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>

Btrfs-progs: make btrfs-image restore with a valid chunk tree V2

Previously btrfs-image would set a METADUMP flag and would make one big system
chunk to cover the entire file system in the super in order to get around the
unpleasant business of having to adjust the chunk tree.  This meant that you
could use the progs stuff on a restored file system, which is great for testing
btrfsck and other such things.  But we want to be able to run the tree log
replay on a file system that is not able to run the tree log replay.  So in
order to do this we need to fixup the super's chunk array and the chunk tree
itself.  This is pretty easy since we restore using the logical offsets of the
metadata, so we just have to set the chunk items to have 1 stripe and have the
stripes point at the primary device and then use the logical offset of the chunk
as the physical offset.  With this patch I can restore a file system image that
had a tree log and mount the file system and have the log be replayed
successfully.  This patch also gives you the -o option in case you want the old
restore way, in the case where we want to make sure the system chunks as they
were given to us are correct.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: make btrfs-image grab the free space cache

A lot of tree log replay bugs are because of strange space cache setups, so make
btrfs-image scrape the free space cache as well so we can better replicate what
a user is seeing if they have a tree log bug or anything related to free space
cache.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: make btrfs-image copy the tree logs if they exist

Currently btrfs-image doesn't copy the tree logs, which doesn't help me when
we're trying to debug log replay bugs.  Since we don't have entries in the
extent root for the blocks we have to walk down all of the trees in order to
copy them.  With this patch I can image a file system with a tree log and it
works fine.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: cleanup error handling in btrfs-image

We use BUG_ON() everywhere in btrfs-image.  When users are going to use this
command things are pretty dire, so I'd rather have really good error messages so
I know what happened rather than figure out which one of the 20 BUG_ON()'s made
the stupid thing exit early.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Btrfs-progs: tool to visualize fragmentation

This tool draws per-chunk pngs representing the allocation map. A black
or colored dot means the block is allocated.
The output is written to a subdirectory, together with an index.html to be
viewed in a browser.
There are options to control whether color should be used and which block
group types should be printed.
To build, you need to have libpng and libgd installed. It is not part of
the 'all' target, so please build it explicitely with make btrfs-fragments.

A (rather untypical) example can be seen at

http://sensille.com/fragments

Please regard this as a first scratch version and feel free to improve it :)

Signed-off-by: Arne Jansen <sensille@gmx.net>

Btrfs-progs: make scrub IO priority configurable

The btrfs tool is changed in order to support command line parameters
to configure the IO priority of the scrub tasks. Also the default is
changed. The default IO priority for scrub is the idle class now.

The behavior is the same as when one would type
'ionice ... btrfs scrub start ...' or 'ionice ... btrfs scrub resume ...'
(without this patch applied).
The only reason for adding this to the btrfs tool is that it was not
documented and not obvious that it worked like this, that all internal
scrub tasks inherited the IO priority values of the btrfs tool that is
starting or resuming the scrub operation.

Note that after applying the patch it is no longer possible to set
the IO priority using ionice since the btrfs tool always configures
the priority in order to run in the idle class by default.

Some basic performance measurements have been done with the goal to
measure which IO priority for scrub gives the best overall disk data
throughput. The kernel was configured to use the CFQ IO scheduler
with default configuration and without support for throttling. The
summary is, that the more the disk head movements are avoided, the
faster the overall disk transfer capacity is, which is not really a
big surprise. Therefore it makes sense that the best data throughput
was measured setting the scrub IO priority and the scrub readahead
IO priority to the idle class priority. Running with idle class IO
priority means that scrub and scrub readahead IO is paused while
other tasks access the disk. Doing the tasks one after the other
instead of concurrently avoids many disk head movements. The
overall data throughput of rotating disks is improved this way.

However, if it is desired to have the scrub task done within a
reasonable time, and if at the same time the filesystem is heavily
loaded, the idle IO priority should be avoided. Otherwise the scrub
operation will never take place and thus never terminate.

The best effort IO priority class with the subclass 7 (the lowest
one in the best effort class) is recommended in the case of always
heavily loaded hard disks. If the filesystem is not loaded all the
time and leaves some idle slots for scrub, the idle class IO priority
is recommended. The idle class now is the default if the scrub
operation is started with the btrfs-progs tools.

Note that the patch that sets the scrub readahead IO priority to the
idle class is a seperate patch, this needs to be done in the kernel.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>

btrfs-progs: makefile: clean static targets

* create .static.o version from the library objects as well and use them
  for building static targets
* remove build dependencies on libbtrfs.*
* other minor cleanups

Signed-off-by: David Sterba <dsterba@suse.cz>

Removing btrfsctl, btrfs-vol, btrfs-show

With the commit 002d021c (committed October 2011)
btrfsctl, btrfs-vol, btrfs-show were declared deprecated.
The last patches related to these commands are dated December 2010.

These tools are replaced by the "btrfs" tool in all the
functionality.

This commit removes all the related code.

Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
Signed-off-by: David Sterba <dsterba@suse.cz>

Makefile: allow user set LDFLAGS for libbtrfs.so as well

Detected by gentoo's QA checker:

 * QA Notice: Files built without respecting LDFLAGS have been detected
 *  Please include the following list of files in your report:
 * /usr/lib/libbtrfs.so.0.1

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Btrfs-progs: fix memory leaks on cleanup

I've been working on btrfs-image and I kept seeing these leaks pop up on
valgrind so I'm just fixing them.  We don't properly cleanup the device cache,
the chunk tree mapping cache, or the space infos on close.  With this patch
valgrind doesn't complain about any memory leaks running btrfs-image.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

btrfs-progs: defrag return zero on success

Signed-off-by: Anand Jain <anand.jain@oracle.com>

Btrfs-progs: fix segfault when using tools fs with tree log

We just free the log root after we set it up when we open a ctree in the tools.
This isn't nice, it makes double free's and leaks eb's, makes segfaults with
btrfs-image.  So fix this to be correct, and fix the cleanup if the buffer is
not uptodate.  With this fix I no longer segfault trying to do btrfs-image on a
file system with a log tree.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>

btrfs-progs: convert: access name_len and file_type the old way

We can't use ext2_dir_entry_2 typecast on big endian machines directly.
The bytes do not get converted during extX block read due to missing
flag EXT2_DIRBLOCK_V2_STRUCT passed down to ext2fs_read_dir_block4 from
ext2fs_process_dir_block. Fixing on the ext2 side needs updating callers
and (maybe) the library interfaces. We'll fix it on the convert side for
now.

CC: Jan Kara <jack@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.cz>

Btrfs-progs: give restore a list roots option

Since restore has the ability to open really really screwed up file systems, add
a list roots option to it so we can still get the contents of the tree root on a
horribly broken fs.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>

btrfs-progs: add lzo compression support to restore

This patch simply adds support to decompress lzo compressed extents in restore.

Signed-off-by: Josef Bacik <josef@redhat.com>

restore: Split output directory and btrfs-local path search_dir() parameters

search_dir() recurses down the btrfs tree, and used to take the output
path for every item (i.e. in the running system, output root directory
concatenated with btrfs-local pathname) passed as the only path
parameter. Moving the output root directory to a separate parameter
and passing the btrfs-local pathname for each file and directory
separately allows easy filtering based on the btrfs-local pathname.

Signed-off-by: Peter Stuge <peter@stuge.se>
Signed-off-by: Josef Bacik <josef@redhat.com>

btrfs-progs: Fix error handling for failed reads in restore tool when mirrors exist

Signed-off-by: David Marcin <djmarcin@google.com>

Btrfs-progs: try other mirrors on read failure

If we hit a bad disk and the read doesn't work, try other mirrors in case we
have other disks with good copies.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>

Btrfs-progs: try other mirrors if decompression fails

This will make the restore program fall back on other mirrors if it fails to
decompress an extent for whatever reason.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>

Btrfs-progs: add an option for specifying the root to restore

If the normal fs tree is hosed and the user has multiple subvolumes it's handy
to be able to specify just one of the subvolumes to restore.  It's also handy if
a user only wants to restore say /home instead of his entire disk.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>

btrfs-progs: mkfs: add missing raid5/6 description

Signed-off-by: Matias Bjørling <m@bjorling.me>

btrfs-progs: document force option in mkfs usage(); add long opt

I missed updating the mkfs.btrfs usage() when I added the
option to force fs overwrite.

Update that, and while we're at it add a long option, since
all other commands have long counterparts.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: print errno string when /dev/btrfs-control open fails

Of recently and intermittently I am seeing open fail
for /dev/btrfs-control (btrfs is loaded), and there are no
dmesg errors, this may not be a complete help in digging
this issue but something which is necessary.
Thanks

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>

btrfs-progs: update .gitignore file

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>

btrfs-progs: add Makefile rule for static build of btrfs-find-root

btrfs-find-root isn't yet integrated into the main btrfs tool, and is
an important recovery tool, so it deserves to be built as a static
binary.

Signed-off-by: Hugo Mills <hugo@carfax.org.uk>

btrfs-progs: rework get_fs_info to remove side effects

get_fs_info() has been silently switching from a device to a mounted
path as needed; the caller's filehandle was unexpectedly closed &
reopened outside the caller's scope.  Not so great.

The callers do want "fdmnt" to be the filehandle for the mount point
in all cases, though - the various ioctls act on this (not on an fd
for the device).  But switching it in the local scope of get_fs_info
is incorrect; it just so happens that *usually* the fd number is
unchanged.

So - use the new helpers to detect when an argument is a block
device, and open the the mounted path more obviously / explicitly
for ioctl use, storing the filehandle in fdmnt.

Then, in get_fs_info, ignore the fd completely, and use the path on
the argument to determine if the caller wanted to act on just that
device, or on all devices for the filesystem.

Affects those commands which are documented to accept either
a block device or a path:

* btrfs device stats
* btrfs replace start
* btrfs scrub start
* btrfs scrub status

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: don't open-code mountpoint discovery in scrub cancel

cmd_scrub_cancel had its own mountpoint discovery routine;
just use open_path_or_dev_mnt() for that now.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: three new device/path helpers

Add 3 new helpers:

* is_block_device(), to test if a path is a block device.
* get_btrfs_mount(), to get the mountpoint of a device,
  if mounted.
* open_path_or_dev_mnt(path), to open either the pathname
  or, if it's a mounted btrfs dev, the mountpoint.  Useful
  for some commands which can take either type of arg.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>

btrfs-progs: close fd on return from label get/set functions

Somehow missed these 2 in the last round.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>