Re: BTRFS not mountable, recover won't work

[Malte Eggers <m.eggers@campus.tu-berlin.de>]

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