OK so I have recovered all of my data. This was sort of a nerve wrecking experience. I'll share what I've done in case others are experiencing the same problem (I've seen other threads appear complaining of the same assertion which draw no response).
So, I filled open_ctree_fd with printf statements to find exactly where it was failing. I found (per my previous mail to this list) that the assertion was happening in the following call: ret = find_and_setup_root(tree_root, fs_info, BTRFS_CSUM_TREE_OBJECTID, csum_root); I also found that the fs would mount read-only on an older kernel but 85% of the files read reported I/O errors. It looks like the b-tree which stores checksums was broken. The breakage is likely high up on the tree and thus affects most, but not all files. Trying to determine how to get btrfs to ignore checksums lead me here: http://kerneltrap.org/mailarchive/linux-btrfs/2010/2/25/6806053/thread#mid-6806053 So I grabbed a copy of 2.6.32.10 and patched compression.c and inode.c. I'm now able to read ALL of the data when mounting read-only. This whole process has left a bit of bad taste in my mouth. A checksum tree seems like a great way to add fault tolerance but in this case it was another point of failure, rendering perfectly uncorrupted data unaccessible. I suppose this would have to be something a proper fsck would have to contend with. My questions for the developers are: 1. Would repairing or rebuilding a broken checksum tree be a trivial task for a functional fsck? 2. Does a mount option which ignores the checksum tree altogether make sense? Strictly for recovery purposes of course. Not everyone is inclined to hack the kernel to get access to their data. Either way I've kept the dump of the broken filesystem. If fsck ever makes it out of development purgatory I'll definitely be running it against this as a test case. I saw an email to this list earlier today asking about the status of fsck. It seems like an it would be reasonable to know approximately when something will be released to the public. Not asking for a specific day, more like which quarter of which year. -- 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
