On Mon, Sep 24, 2012 at 03:02:39PM +0100, Hugo Mills wrote:

quoted

root@sysresccd /root/btrfs-progs % ./btrfsck --super 2 /dev/patience/home
using SB copy 2, bytenr 274877906944
Check tree block failed, want=139264, have=0
Check tree block failed, want=139264, have=0
Check tree block failed, want=139264, have=0
read block failed check_tree_block
Couldn't read chunk root

If I'm interpreting the output correctly, it's trying to read bytes
from address 139264, which would fall into the corrupted area.

   No, I believe the "want=, have=" text is referring to a generation
ID, not a block number. That's not to say that your chunk tree isn't
damaged, though -- I'm just clarifying your interpretation of the
numbers.

  40 static int check_tree_block(struct btrfs_root *root, struct extent_buffer *buf)
  41 {
  42
  43         struct btrfs_fs_devices *fs_devices;
  44         int ret = 1;
  45
  46         if (buf->start != btrfs_header_bytenr(buf)) {
  47                 printk("Check tree block failed, want=%Lu, have=%Lu\n",
  48                        buf->start, btrfs_header_bytenr(buf));
  49                 return ret;
  50         }

No, it's the block address in bytes, 4k-block number 34.

   Out of interest, does mounting with -o recovery help at all? (I'm
not expecting it to do much if your chunk tree's gone, but it might do
something).

The -o recovery has access to the respective tree roots, but the
contents may be destroyed already. The chunk tree is not deep, I can see
height 1 on a 6 disk array (though lightly used, 1 node, 8 leaves) and 3
disk array (1/7 TB used, 1 node, 29 leaves). So it's quite a small
amount of data to destroy the chunktree completely, COW will lower the
chances a bit.

Rebuilding from scratch does not look simple, the available information
is stored in BLOCK_GROUP_ITEMs or INODE_ITEMs and covers portions of the
chunks. Given that the device tree would be probably damaged as well,
the amount of information to do cross-check is not high. Maybe replaying
the chunk creation logic can save some guesswork.


david