From: David Woodhouse on
On Thu, 2010-07-08 at 10:31 -0400, Chris Mason wrote:
> Neither Yan nor I have been able to reproduce this locally, but a few
> people have now hit it. Johannes, are you available to try out a
> debugging kernel to try and track this down?

I have a machine you can log into, with a spare file system that causes
this. It's 200GiB so non-trivial to upload, unless you have a tool like
the xfs one which extracts just the important data structures and leaves
all the data extents and free space as zero.

It was created with the MeeGo 2.6.33.6 kernel -- which I don't think
contains commit 7f0e7bed which is later alleged to be the cause.

I've also tried booting this machine with a current kernel from git,
which includes commit 83ba7b07 which is alleged to be a fix -- and btrfs
still oopses just the same.

btrfsck and btrfs-dump-tree both abort with:
extent-tree.c:1755: update_space_info: Assertion `!(found->total_bytes < found->bytes_used)' failed.

I can mount it read-only though and read certain things out of it. But
when I boot from it, I hit the BUG().

--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/