btrfs/ctree.py | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 [patch] ctree: fix crash because of stray underscores

The tree_block_refs and shared_block_refs attributes of the MetaDataItem
class are of type list. This means they have an append function, and not
_append.

So hitting these lines of code crash a program with "AttributeError:
'list' object has no attribute '_append'"

This made me find out that both of the filesystems that I use for
regression testing before doing a release were originally created using
Debian Jessie, and they were never converted to enable the
skinny_metadata feature, which introduces the usage of these
MetaDataItem objects.

Unfortunately this means that working with metadata related information
from the extent tree is pretty much broken for any recently created
filesystem. Also affected is the btrfs-heatmap program, which will crash
while generating pictures on extent level of metadata block groups.

Andrei Borzenkov reported this bug, and found it by using the
show_metadata_tree_sizes example.

Fixes: 899fdf4c52 "ctree: hide internal ref item helpers"
Closes: https://github.com/knorrie/python-btrfs/issues/17

bin/btrfs-space-calculator | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 [patch] space-calculator: quickfix crash when using raid5

Andrei Borzenkov reported that when using raid5 in the options, the
program crashes:

  File "/home/bor/src/python-btrfs/bin/btrfs/volumes.py", line 192,
      in chunk_length_to_dev_extent_length
    dev_extent_length = raw_data_bytes // num_data_stripes
ZeroDivisionError: integer division or modulo by zero

The way this space calculator works is a little bit naughty. By
constructing some fake replacements for the official Chunk, Stripe etc
classes, we fool the usage report module and have it believe it's
looking at an actual filesystem.

In order to do so, we need to present at least one fake chunk of each
chosen profile (for data, metadata etc) to it, so it can take over from
there and do a simulation filling up the rest of the raw space.

The FakeChunk had num_stripes = 1 hardcoded, which obviously is fragile.
In the specific case of RAID5, it crashes because the nparity is
subtracted from num_stripes, which makes it 0.