On Mon, 2017-04-10 at 16:53 +0800, Qu Wenruo wrote: > > At 04/10/2017 04:37 PM, Malte Eggers wrote: > > On Mon, 2017-04-10 at 16:18 +0800, Qu Wenruo wrote: > > > > > > At 04/10/2017 01:17 AM, Malte Eggers wrote: > > > > Hi, > > > > > > > > After suspending and waking up my laptop with the external hard > > > > drive > > > > connected, I could no longer access the files on it. So I > > > > unmounted > > > > and > > > > remounted it, only to discover that I could no longer mount it. > > > > > > > > > > > > This is the error (mounting with usebackuproot, same error > > > > without): > > > > > > > > [891667.002861] BTRFS info (device dm-0): trying to use backup > > > > root > > > > at > > > > mount time > > > > [891667.002870] BTRFS info (device dm-0): disk space caching is > > > > enabled > > > > [891667.002876] BTRFS info (device dm-0): has skinny extents > > > > [891667.016395] BTRFS error (device dm-0): parent transid > > > > verify > > > > failed > > > > on 108855296 wanted 32139 found 32104 > > > > [891667.017181] BTRFS error (device dm-0): parent transid > > > > verify > > > > failed > > > > on 108855296 wanted 32139 found 32104 > > > > [891667.017194] BTRFS error (device dm-0): failed to recover > > > > balance: > > > > -5 > > > > > > What about trying skip_balance mount option to skip balance > > > > Tried that, same error > > > > > > > [891667.078829] BTRFS error (device dm-0): open_ctree failed > > > > > > > > > > > > btrfs restore and btrfs-find-root fail like this (on both > > > > debian > > > > sid > > > > and fedora 25): > > > > > > > > parent transid verify failed on 108806144 wanted 32139 found > > > > 32104 > > > > parent transid verify failed on 108806144 wanted 32139 found > > > > 32104 > > > > parent transid verify failed on 108806144 wanted 32139 found > > > > 32104 > > > > parent transid verify failed on 108806144 wanted 32139 found > > > > 32104 > > > > Ignoring transid failure > > > > > > Would you please paste the output of "btrfs-debug-tree -b > > > 108806144 > > > /dev/dm-0" ? > > > > > > > volumes.c:1645: btrfs_chunk_readonly: BUG_ON `!ce` triggered, > > > > value > > > > 1 > > > > > > This BUG_ON() means we can't find a corresponding chunk for given > > > offset. > > > > > > "btrfs-debug-tree -t chunk" would help, if it executes without > > > problem. > > > > btrfs-debug-tree produces the same error > > > > > > If "btrfs-debug-tree" can't even open the fs, then "btrfs > > > inspect-internal dump-super -f /dev/dm-0" would help them. > > > > dump-super finishes as it appears without error: https://pastebin.c > > om/t > > i8xuuR5 > > How would I proceed from here? > > The obvious problem I found is that, system chunk at bytenr 0 seems > invalid. > The physical address of that chunk is devid 1 offset 0, which is not > possible as 0~1M is reserved. > > According to the backtrace of btrfs-progs, it seems to be related to > chunk tree corruption. > Which btrfs chunk recovery may help. > > It's recommended to backup your system chunks and superblocks first. > ------ > # Backup sys chunks > dd if=/dev/dm-0 of=sys_chunk1_stripe_0 bs=1 count=8388608 > skip=20971520 > dd if=/dev/dm-0 of=sys_chunk1_stripe_1 bs=1 count=8388608 > skip=29360128 > dd if=/dev/dm-0 of=sys_chunk0_stripe_0 bs=1 count=4194304 skip=0 > # Backup first superblock > dd if=/dev/dm-0 of=superblock0 bs=1 count=4k skip=64k > ------ > > Then try chunk recovery > ------ > btrfs rescue chunk-recover /dev/dm-0 > ------ > > It can be very slow since it may scan the full device. > > Thanks, > Qu > > > > Thanks, > > > Qu > > > > Thank you > > > > > Is there any way to just rescue whatever can still be reconstructed? Cheers, Malte -- 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
