Am 30.12.2019 um 02:38 schrieb Qu Wenruo: > > Normally crash shouldn't corrupt btrfs, it's either btrfs bug or > something else causing corruption. The file system had been corrupted after the hard disk (WD Gold 6 TB WD6002FRYZ) that had been transfered from a PC to an external enclosure that failed during read operations. The disk could not be mounted anymore. According to SMART the drive itself does not have errors. # dmesg BTRFS info (device sdc1): disk space caching is enabled BTRFS info (device sdc1): has skinny extents BTRFS error (device sdc1): parent transid verify failed on 97288192 wanted 248243 found 248241 BTRFS error (device sdc1): parent transid verify failed on 97288192 wanted 248243 found 248241 BTRFS error (device sdc1): failed to read block groups: -5 BTRFS error (device sdc1): open_ctree failed Mounting with mount -t btrfs -o rootflags=recovery,nospace_cache mount -t btrfs -o ro,rescue=skip_bg mount -t btrfs -o ro,usebackuproot did not work either. Similar error with btrfs-find-root # btrfs-find-root /dev/sdc1 parent transid verify failed on 97288192 wanted 248243 found 248241 parent transid verify failed on 97288192 wanted 248243 found 248241 parent transid verify failed on 97288192 wanted 248243 found 248241 parent transid verify failed on 97288192 wanted 248243 found 248241 Ignoring transid failure ERROR: child eb corrupted: parent bytenr=71925760 item=38 parent level=2 child level=0 Superblock thinks the generation is 248274 Superblock thinks the level is 1 Found tree root at 71794688 gen 248274 level 1 Well block 43712512(gen: 248228 level: 1) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 34603008(gen: 247269 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 34078720(gen: 247269 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 33931264(gen: 247269 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 33325056(gen: 247269 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 30375936(gen: 247269 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 30425088(gen: 247268 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 Well block 30408704(gen: 247268 level: 0) seems good, but generation/level doesn't match, want gen: 248274 level: 1 btrfs rescue zero-log with a file copy of the partition also gave errors. I've also tried to apply the patch you have provided with https://patchwork.kernel.org/project/linux-btrfs/list/?series=130637 but unfortunately it does not apply to the Linux kernel sources I've used (5.3.13). During btrfs restore I encountered errors of the form offset is ... We seem to be looping a lot on /path/to/file.dat, do you want to keep going on ? (y/N/a): y ... offset is ... ERROR: cannot map block logical 1643391221760 length 3221225472: -2 Error copying data for /path/to/file.dat Error searching /path/to/file.dat Error searching /path/to/file.dat This led me to the conclusion that the file system is being corrupted. > The restore doesn't check data csum. And by default it reads the first > copy of data. > > If the read succeeded, btrfs-restore just call it a day, thus no data > csum verification or anything else. > > So it's not as good as you would expect. This sounds bad. What is the rationale behind btrfs restore not verifying checksums? I would expect a file with errors not to be restored (without opting for doing so). And even worse, there are cases where a "restored" file could be synchronized with other storage locations and spread corruption this way. > Anyway, btrfs-restore is the last resort method, before that RO mount > and various rescue mount options should be tried before it. > Kernel will always verify data csum. Are there any options left to get all files that have not been corrupted back? -- Thank you very much, Alex
