At 04/13/2017 07:45 PM, Malte Eggers wrote:
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
The problem is that, btrfs fails to build its chunk maps.
Unlike traditional fs, btrfs uses dynamically allocated chunk maps, so
if btrfs fails to build its maps, nothing can be read out.
That's why we have special purposed chunk recover command, due to the
importance of chunk maps.
(Although it doesn't work as expected sometimes)
Thanks,
Qu
--
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
--
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
