On 2019/7/29 下午10:21, Swâmi Petaramesh wrote:
> Le 29/07/2019 à 16:08, Qu Wenruo a écrit :
>> You don't need to repair.
>>
>> The corruption is in extent tree, to read data out you don't need extent
>> tree at all.
>
>> 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.
>
>
> Basically my question is : Is there anyway I can turn this broken FS
> into a sane FS using « btrfs repair » EVEN if this causes data losses ?
>
> I can afford some data losses of this backup disk (next backup will fix
> missing files)
>
> But I DO NOT want to lose (or have to recreate) the complete FS with all
> its subvols and snapshots, which I have no other disk to copy to currently.
>
> So I can accept a « fix with losses », but not a « well you need to
> reformat the disk completely »...
Then you can try, but we can't ensure anything. The problem is, as long
as CoW is already broken once, especially when extent tree is corrupted,
it's very easy later write breaks CoW again due to corrupted extent
tree, thus make things worse.
The rescue method provides full access, including subvolume and things
like that, the only problem is everything is RO.
To be clear again, btrfs check --repair is never ensured to make the
image to be usable (pass btrfs check after repair), especially when
extent tree corruption is involved.
BTW, I'm more interesting in your other corrupted leaf report other than
this transid error.
The later one is either some real corruption from older fs, or some
false alerts needs to be addressed.
Thanks,
Qu
>
> Kind regards.
>
> ॐ
>
