On 2017年12月11日 05:16, Benjamin Beichler wrote: > The patch let the chunk-recover be successful. But I'm no lucky man, > the recovered chunk tree does not work or other metadata is also > broken. > > Mounting the system is not successful (dmesg): > BTRFS critical (device dm-0): corrupt node, invalid item slot: > block=16384, root=1, slot=0
What does btrfs dump-tree -b 16384 say? IIRC the same 0 bytenr problem in kernel. > BTRFS error (device dm-0): failed to read chunk root > BTRFS error (device dm-0): open_ctree failed > > Therefore I tried a btrfs check --repair, this time without error: > https://gist.github.com/anonymous/5cf7ad9e187032d2c94db4f91bb62c24 > > Then I tried btrfs check --init-extent-tree and this produces much > output. I put the beginning into here: > https://gist.github.com/anonymous/70e2482646a8235ee2327105d920dadd That's common for --init-extent-tree, but I don't think extent tree is related in this case. Thanks, Qu > From a fast view, the messages keep to be similar to the last of the > gist, but the messages in the beginning are not repeating. If it helps > I have complete compressed log. > > Then I tried a btrfs recover to get files, but for many files (also > improtant data, but I filtered the output) I get outputs like in: > https://gist.github.com/anonymous/1cc7f7ab5af33e76d0bf80960bb300eb> > Any new suggestions? >
signature.asc
Description: OpenPGP digital signature
