On 2018年03月14日 17:36, Dirk Gouders wrote: > Qu Wenruo <quwenruo.btrfs@xxxxxxx> writes: > >> On 2018年03月14日 16:53, Dirk Gouders wrote: >>> Qu Wenruo <quwenruo.btrfs@xxxxxxx> 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) > > I am currently preparing the diagnosis data but after the above bytenr > the log grew to already 28MB. Should I send all that data to the list? Nope, stderr is enough. Thanks, Qu > > Thanks, > > Dirk > >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
