Re: Rebuilding chunk root?
On Mon, Sep 24, 2012 at 04:28:08PM +0300, Sami Haahtinen wrote: Due to certain unfortunate chain of events, I managed to overwrite a small portion of my btrfs array which had only single redundancy for metadata. The data itself is present and only a small portion (2.5%) of the array was overwritten. After quite a bit of debugging and tinkering, I realized that my chunk root was in the portion that was overwritten. After reading through the documentation I was able to pull together it's still unclear to me whether chunk root is something that can be rebuilt. Chris had some experimental code for doing it in btrfsck which never saw the light of day (because it was too unreliable). He may be able to offer you something to help, though. A transcript of btrfsck trying to recover with superblock 2 which is uncorrupted by itself: 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. 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). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Eighth Army Push Bottles Up Germans -- WWII newspaper --- headline (possibly apocryphal) signature.asc Description: Digital signature
Re: Rebuilding chunk root?
On Mon, Sep 24, 2012 at 03:02:39PM +0100, Hugo Mills wrote:
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,
48buf-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
--
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
Re: Rebuilding chunk root?
On Mon, Sep 24, 2012 at 6:12 PM, David Sterba d...@jikos.cz wrote: On Mon, Sep 24, 2012 at 03:02:39PM +0100, Hugo Mills wrote: 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. Yeah, the whole tree is gone, I'm pretty sure of it since the first 20-50GB has been wiped from the drive and the mentioned address is in the beginning of that part. I just wonder if there is any chance of the older versions of the chunk tree still being somewhere and how to find them. I doubt it's an easy feat though. 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. Replaying chunk creation logic would not help that much, since the drive has been resized a few times and had other operations that have modified the chunk tree as well. The array itself is not that complex (2 drives), but it's still not as simple as a single drive array. Regards, -- Sami Haahtinen Bad Wolf Oy +358443302775 -- 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
