On 2018/12/30 上午7:56, Josh Holland wrote: > Hi, > > My btrfs partition will not mount. I spent some time in the IRC, where > darkling said it was due to checksum errors, but we couldn't find a solution. > The kernel version is 4.19.12 and btrfsprogs are at 4.19.1. Unfortunately I > wasn't able to get a network connection on the computer in question, so > instead of using a pastebin I shared pictures from my phone, linked below. > > dmesg errors: https://oc.inv.alid.pw/s/ZHdJprfg4ZQmXWG
Good report, it shows the error straightforward. One (or all) tree block of your root tree is corrupted. Thus btrfs fails to mount. Normally it really means some data doesn't match on disk. It's really recommended to check the SMART info or check if your underlying dm devices doesn't have something wrong. > btrfs check output: https://oc.inv.alid.pw/s/JabKEqpXG3greq3 BTW, super block number starts from 0, max to 2, and your devices is not large enough to have the 3rd super block. Despite that, it shows the same error as kernel. > btrfs inspect dump-super: https://oc.inv.alid.pw/s/RqKSRkg7Z7n8AyF Since it's root tree corruption, you don't have much chance. But you could still try to use backup roots. You could user dump-super -f to show backup roots like: $ btrfs ins dump-super -f <device> | grep backup_tree_root backup_tree_root: 30408704 gen: 400 level: 1 backup_tree_root: 753545216 gen: 397 level: 1 backup_tree_root: 760516608 gen: 398 level: 1 backup_tree_root: 759857152 gen: 399 level: 1 Then try "btrfs check -r <number> <device>" to see if any of them has a better result. Thanks, Qu > > I'll probably end up restoring this from my backups, but I'd prefer not to > have to do that unless it's really necessary. Any help is much appreciated; > I'll try getting the network up to paste the errors in plain text tomorrow, > along with a full copy of dmesg. > > Thanks, > Josh >
signature.asc
Description: OpenPGP digital signature
