The members of the struct btrfs_ioctl_search_header are already in the
native endianess and these don't need a conversion little endian ->
native format. So drop the get_u32()/get_u64() call for these.

This is not a problem in the x86 world, which is little endian. But
in the (e.g.) ppc world, the native format is big endian so using a
get_u32()/get_u64() functions cause an incorrect conversion le -> be
when the values are already in the native format.

At the same time replace the get_u32()/get_u64() function with the
get_unaligned_[le]32/64() functions.

Signed-off-by: Goffredo Baroncelli <kreijack@libero.it>

No logic for partially used extents yet.

Not handling __CHECKER__.

Closes #42

Closes #41

Closes #39

This brings a massive speedup: 58.768s -> 2.010s on my sbuild disk.
We spend most of time zeroing a buffer to read files with 1-2 extents.

Noticing this is Zygo Blaxell's fault: praise him with great praise!

Closes: #30

_FILE_OFFSET_BITS is already set to 64

Closes #19

In Debian they got split out of btrfs-progs into libbtrfs-dev.

Even though we're root, can still happen on sshfs or such mounts.

Doubled / is harmless (not on Windows...), but would confuse people.

The latter should be easy to fix if the radix implementation is replaced.

Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>

Self-explaining now, so removed.

Closes #12

A non-sparse compressed file without extra fragmentation will hit this
at 24GB.

Closes #10

Closes #11

It wasn't obvious enough.

Closes #8

The table is misaligned for >= 1 drivemaker's terabyte, but as this output
isn't really meant for human reading, this probably doesn't matter.