On 2018年03月14日 16:53, Dirk Gouders wrote: > Qu Wenruo <quwenruo.bt...@gmx.com> writes: > >> On 2018年03月13日 22:49, Dirk Gouders wrote: >> [snip] >>>> >>>> # btrfs inspect dump-tree -b 848986112 /dev/loop0p1 >>>> # btrfs inspect dump-tree -b 72089600 /dev/loop0p1 >>> >>> OK. >>> >>> (This mail gets a bit long but I don't want to snip probably important >>> information above.) >>> >> >> Feel free to snip. >> As the involved tree block is not shown anywhere. >> >> So it's not any root node corrupted. >> It may be some extent tree node corrupted in this case. >> >> While to inspect it, we need some new functionality in btrfs inspect tree. >> >> Before that, would you please try the following patch and to see if it >> helps btrfs-restore to salvage any data? > > I tried it and got the following output: > > # btrfs restore /dev/loop0p1 /mnt/ > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > checksum verify failed on 363069440 found DC09290B wanted C630FD61 > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > bytenr mismatch, want=363069440, have=17552567724568668829 > Could not open root, trying backup super > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > checksum verify failed on 363069440 found DC09290B wanted C630FD61 > checksum verify failed on 363069440 found 296FB15A wanted F0AFE59D > bytenr mismatch, want=363069440, have=17552567724568668829 > Could not open root, trying backup super > ERROR: superblock bytenr 274877906944 is larger than device size 10741612544 > Could not open root, trying backup super
So it's still something important in the tree. Would you please apply this patch? https://patchwork.kernel.org/patch/10281329/ And then dump the tree again using that newly added -f option? (Both stdout and stderr is needed) The dump command would be: # btrfs inspect dump-tree -f -b <bytenr> Needed bytenrs would be: 848773120 tree root 848789504 extent root (My primary guess) 30408704 dev root 850509824 fs root (this could contain *FILENAME*, please censor them if needed, and it may be large) 212353024 uuid tree (not really imporatant) And if it's extent root, we could enhance btrfs-progs open_ctree() to handle it for RO mode (needed by btrfs-restore) 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 >
signature.asc
Description: OpenPGP digital signature
