python-btrfs v5, yay

[Hans van Kranenburg <hans.van.kranenburg@mendix.com>]

I just tagged v5 of the python btrfs library:

https://github.com/knorrie/python-btrfs

>From CHANGES:

python-btrfs v5, Jan 14 2017
  * Revamp and fix loading of extent backreferences.
  * Explode when detecting a non x86_64 arch.
  * Add a crc32c implementation and example script to create
    a dir_item offset hash.

  The biggest change is done in the loading of backreferences of data
and metadata extents. The way it was done was plain wrong in a number of
cases and ignored/missed a bunch of types of objects. See the commits
since v4 and their messages for much more detailed info.

  And, instead of fixing the library to work correctly for non-amd64
users, it currently explodes preventively, which is at least better than
using wrong IOCTL numbers.

  The third change, the crc32c addition is a bit of a weird duck in the
bite, but I didn't want to leave it out yet:

In the previous weekend, I was able to help out a user on IRC to repair
a metadata page which had about 10 bytes overwritten with crap (in
memory) that really didn't belong there. btrfs-debug-tree even
segfaulted on the result. By loading a 16kiB metadata page, which was
dd-ed from the disk in python-btrfs with some missing datastructures
hacked in, we ended up with a very convenient way to look around in the
data and set the attributes of two metadata item records to the right
values and write back the page to the 16kiB binary file. Because a
dir_item was involved, which needed to get the right filename crc in the
key offset field again, we had to figure out how to create it, and I
learned that crc32c doesn't mean a single thing, because I took me a
while to find out why every crc32c lib I could find gave me the
consistent same result, being different than what btrfs crc32c would show...

And yes, after writing back the metadata page, the filesystem was usable
again! :-)

Have fun,

-- 
Hans van Kranenburg