Package: python-btrfs / 11-2
Metadata
Package | Version | Patches format |
---|---|---|
python-btrfs | 11-2 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
ctree Fix crash because of stray underscores.patch | (download) |
btrfs/ctree.py |
4 2 + 2 - 0 ! |
[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 |
space calculator quickfix crash when using raid5.patch | (download) |
bin/btrfs-space-calculator |
4 2 + 2 - 0 ! |
[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. |
1