Btrfs-progs: add support for the ENOSPC log

This adds support for the ENOSPC log incompat feature.  We can mkfs with the new
format and we'll read the block groups properly.  Support for clearing the log
will come later.

Signed-off-by: Josef Bacik <jbacik@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>
Btrfs-progs: sanity check the number of items in a leaf

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>
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>
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: 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>