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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
