On 2019/1/16 上午12:33, Christian Schneider wrote: > > Hello all, after a power failure I have issues mounting a btrfs volume: > > mount /dev/md42 > mount: /home: wrong fs type, bad option, bad superblock on /dev/md42, > missing codepage or helper program, or other error > > dmesg > [...] > [ 4322.061000] BTRFS info (device md42): use lzo compression, level 0 > [ 4322.061004] BTRFS info (device md42): disk space caching is enabled > [ 4322.061005] BTRFS info (device md42): has skinny extents > [ 4323.016007] BTRFS error (device md42): parent transid verify failed > on 448888832 wanted 68773 found 68768 > [ 4323.025656] BTRFS error (device md42): parent transid verify failed > on 448888832 wanted 68773 found 68771
Transid error, and furthermore, two copies are pointing to different leaves. So in short conclusion, your fs is screwed up. You could try this patch: https://patchwork.kernel.org/patch/10738583/ Then mount with "ro,skip_bg" mount options. Or go btrfs-restore. > [ 4323.025665] BTRFS error (device md42): failed to read block groups: -5 > [ 4323.036088] BTRFS error (device md42): open_ctree failed > > adding -o ro,usebackuproot doesn't change anything, same mount error, > same error messages in dmesg. > > Also tried btrfs check with this error. > btrfs check /dev/md42 > Opening filesystem to check... > parent transid verify failed on 448888832 wanted 68773 found 68768 > parent transid verify failed on 448888832 wanted 68773 found 68768 > parent transid verify failed on 448888832 wanted 68773 found 68771 > parent transid verify failed on 448888832 wanted 68773 found 68771 > Ignoring transid failure > leaf parent key incorrect 448888832 > ERROR: cannot open file system <snip> > [...] > > The last line repeats with different block numbers with decreasing gen > and level sometimes 0. > > A simple > btrfs filesystem show /dev/md42 > Label: none uuid: 8c6746f0-944a-45c5-90f3-622724d15998 > Total devices 1 FS bytes used 1.63TiB > devid 1 size 7.26TiB used 1.90TiB path /dev/md42 > > for me, seems to be ok. > > Is there something I could try to recover from this? > Any help is welcome, as it happened during backup creation, and the > backup volume suffers from the same issue. > > Additional info of system: > uname -a > uname -a > Linux jane 4.19.6-gentoo #1 SMP PREEMPT Sat Dec 15 13:26:24 CET 2018 > x86_64 Intel(R) Core(TM) i7-4785T CPU @ 2.20GHz GenuineIntel GNU/Linux I'm more interested in the history of the fs. Did the fs get created/modified by some older kernel? Especially considering you're using Gentoo, and every kernel update needs time consuming compile, it may be caused by some older kernel. Thanks, Qu > > btrfs --version > btrfs-progs v4.19.1 > > BR, Christian
signature.asc
Description: OpenPGP digital signature
