On 2020/5/11 上午12:51, Christoph Heinrich wrote: > Hello, > > > > my hard drive can't be mounted anymore. > > Two days ago the drive was very slow (<1kb/s read and write, but I > didn't find any errors anywhere). Something looks tricky, and SMART reports no error? > > However after unplugging and plugging in again, everything seemed normal > again, so I don't know if that's related. > > > > When trying to mount it today I get that error: > > > > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, > missing codepage or helper program, or other error. > > > > Mounting without -o results in dmesg: > > > > [14479.650956] BTRFS info (device sdb): disk space caching is enabled > > [14479.650963] BTRFS info (device sdb): has skinny extents > > [14499.742007] BTRFS error (device sdb): parent transid verify failed on > 3437913341952 wanted 7041 found 6628 > > [14499.753076] BTRFS error (device sdb): parent transid verify failed on > 3437913341952 wanted 7041 found 6628 Either btrfs or the disk failed to write certain data onto disk. This breaks the COW requirement and corrupted the extent tree. There is a pending patch to skip extent tree read, allow user to do RO mount and salvage data, but that's not merged for a long long time. > > [14499.753089] BTRFS error (device sdb): failed to read block groups: -5 > > [14499.816157] BTRFS error (device sdb): open_ctree failed > > > > I already tried mounting with usebackuproot,nospace_cache,clear_cache, > but that resulted in the same error messages as before. Existing rescue options won't help. In this case, your only hope would be salvaging data. Other than that pending patch, btrfs-restore is here. > > > > When running btrfs check I get the output: > > parent transid verify failed on 3437913341952 wanted 7041 found 6628 > > parent transid verify failed on 3437913341952 wanted 7041 found 6628 > > parent transid verify failed on 3437913341952 wanted 7041 found 6628 > > Ignoring transid failure > > ERROR: child eb corrupted: parent bytenr=3437941538816 item=123 parent > level=2 child level=0 Yeah, some write didn't reach disk. This means either the disk is reporting false FLUSH/FUA result (return before all data reach disk), or btrfs has something wrong. If you have run btrfs kernel between 5.2.15~5.3.0, it's possible that one kernel regression caused such problem. > > ERROR: failed to read block groups: Input/output error > > ERROR: cannot open file system > > > > From what I've read so far, running btrfs-zero-log or btrfs check > --repair may help, --repair won't help afaik. But --init-exten-tree may help. The problem is, normally we use btrfs check to do a basic evaluation on how damaged the fs is (mostly to ensure fs trees are all OK). But in your case, btrfs check failed to continue, thus we don't now if that transid error is the only error. So if you want to salvage data, either go btrfs-restore or compile that out-of-tree patch. If you don't care the data, but want to take an adventure, try btrfs check --init-extent-tree, which can screw up the fs even more, or may save your fs to completely fine status. Thanks, Qu > but it may also do more damage then good, so I'd rather ask then make > the situation worse then it already is. > > > > kernel 5.6.11 > > btrfs-progs 5.6 > > > > Regards, > > Christoph
Attachment:
signature.asc
Description: OpenPGP digital signature
