Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

[Chris Mason <clm@fb.com>]

On 07/19/2016 12:06 PM, Chandan Rajendra wrote:
> On Monday, July 18, 2016 03:31:04 PM Omar Sandoval wrote:
>> Yeah, this should definitely not work. It's possible that things are
>> just silently failing and getting corrupted if the module isn't built
>> with CONFIG_BTRFS_ASSERT, but btrfsck v4.6.1 + my patch should catch
>> that.
>>
>> Chandan, is fsx creating enough fragmentation to trigger the switch to
>> bitmaps? You can check with `btrfs inspect dump-tree`; there should be
>> FREE_SPACE_BITMAP items. If there are only FREE_SPACE_EXTENT items, then
>> it's not testing the right code path.
>>
>> I have a script here [1] that I've been using to test the free space
>> tree. When I ran it with `--check` on MIPS, it failed on the old kernel
>> and passed with this series. If you stick a return after the call to
>> `unlink_every_other_file()`, you'll get a nice, fragmented filesystem to
>> feed to xfstests, as well.
>
> You are right, There were only FREE_SPACE_EXTENT items in the filesystem that
> was operated on by fsx. I executed fragment_free_space_tree.py to create a
> filesystem with FREE_SPACE_BITMAP items. When such a filesystem is created
> with the unpatched kernel, later mounted on a patched kernel and fsx executed
> on it, I see that we fail assertion statements in free-space-tree.c. For e.g.
>
> BTRFS error (device loop0): incorrect extent count for 289406976; counted 8186, expected 8192
> BTRFS: assertion failed: 0, file: /root/repos/linux/fs/btrfs/free-space-tree.c, line: 1485
>

Omar, looks like we need to make the patched kernel refuse to mount free 
space trees without a new incompat bit set.  That way there won't be any 
surprises for the people that have managed to get a free space tree 
saved.  Can it please printk a message about clearing the tree and 
mounting again?

-chris