On Tue, Aug 14, 2012 at 01:20:36PM -0500, Peter Marheine wrote:
> Hi all,
>
> I'm running btrfs in a 3-disk RAID1 configuration. After a hard
> power-off, I'm seeing a lot of hung I/O tasks on this volume,
> apparently due to a corrupt leaf. I first noticed the problem on
> kernel 3.4.7, and it's persisted with 3.4.8. Relevant parts of the
> kernel log follow.
What was the filesystem activity when the power-off happened?
>
> [ 85.179621] block group 38684065792 has an wrong amount of free space
> [ 85.179667] btrfs: failed to load free space cache for block group
> 38684065792
> [ 136.969477] btrfs: corrupt leaf, bad key order:
> block=1478255230976,root=1, slot=26
> [ 136.998953] btrfs: corrupt leaf, bad key order:
> block=1478255230976,root=1, slot=26
> [ 137.000492] btrfs: corrupt leaf, bad key order:
> block=1478255230976,root=1, slot=26
> [ 137.000708] btrfs: corrupt leaf, bad key order:
> block=1478255230976,root=1, slot=26
> [ 153.912922] btrfs: corrupt leaf, bad key order:
> block=1478255230976,root=1, slot=26
> [ 153.913020] ------------[ cut here ]------------
> [ 153.913055] kernel BUG at fs/btrfs/inode.c:828!
809 static noinline int cow_file_range(struct inode *inode,
810 struct page *locked_page,
811 u64 start, u64 end, int *page_started,
812 unsigned long *nr_written,
813 int unlock)
814 {
[...]
828 BUG_ON(btrfs_is_free_space_inode(root, inode));
plus the 'block group' warning above, this seems to be the but that Liu Bo
fixed with patches
Btrfs: fix a bug of writting free space cache with nodatacow option
Btrfs: fix a bug of writting free space cache during balance
Btrfs: fix btrfs_is_free_space_inode to recognize btree inode
that should appear in 3.6.
You can try to mount with 'nospace_cache' or 'clear_cache' if this would make a
difference to redo the space cache from scratch, but I'm afaraid the bad keys
will remain and would have to be removed via offline fsck.
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
