On 2019/7/29 下午10:01, Swâmi Petaramesh wrote:
> Le 29/07/2019 à 15:52, Swâmi Petaramesh a écrit :
>>
>> Please tell me how I could help.
>
> Here is the complete output of BTRFS check, ressembling exactly to what
> I saw on the 1st disk that broke.
>
> QUESTION : If I run « btrfs check » in repair mode, is there any hope it
> will repair the FS properly - I can afford to lose the damaged files,
> that's not a problem for me.
You don't need to repair.
The corruption is in extent tree, to read data out you don't need extent
tree at all.
You can experiment with the following patchset:
https://patchwork.kernel.org/project/linux-btrfs/list/?series=130637
>
>
...
> Wrong key of child node/leaf, wanted: (1797454, 96, 23), have:
> (18446744073709551606, 128, 2538887163904)
Unfortunately, some of your fs tree is also corrupted during that CoW
breakage.
The following output is your the corrupted files.
> root 2815 inode 1797454 errors 200, dir isize wrong
> root 2815 inode 1797455 errors 2001, no inode item, link count wrong
> unresolved ref dir 1767611 index 5 namelen 2 name fs filetype 2 errors
> 4, no inode ref
[...]
> ERROR: errors found in fs roots
But I'd say you would have a good chance to salvage a lot of data at least.
BTW, --repair may help, but won't be any better than that skip_bg
rescue, you won't have much chance other than salvaging data.
Thanks,
Qu
> found 1681780068352 bytes used, error(s) found
> total csum bytes: 1634102612
> total tree bytes: 7675002880
> total fs tree bytes: 5528207360
> total extent tree bytes: 374669312
> btree space waste bytes: 1041372744
> file data blocks allocated: 2247597993984
> referenced 1803060187136
> root:~#
>
> ॐ
>
