Re: BTRFS error (device dm-0): parent transid verify failed on 1382301696 wanted 262166 found 22

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/2/28 13:19, Christoph Anton Mitterer wrote:
> On Mon, 2022-02-28 at 08:55 +0800, Qu Wenruo wrote:
>> The corruption part is a tree block in checksum tree (ironically).
>>
>> This corruption makes btrfs unable to read (part of) checksum tree,
>> thus
>> unable to verify a lot of data.
>
> I see... so, can one find out which files are affected by that part of
> the checksum tree?

It may not be a single file, but a lot of files.

As csum tree only stores two things, logical bytenr, and its csum.

So we need some work to find out:

1) Which logical bytenr range is in that csum tree block

2) Which files owns the logical bytenr range.

>
>
>
>> Please note that, scrub only checks the checksum.
>
> Sure, and it fails, presumably then when encountering that broken block
> and stops completely:
> Feb 28 05:56:11 heisenberg kernel: BTRFS error (device dm-0): parent transid verify failed on 1382301696 wanted 262166 found 22
> Feb 28 05:56:11 heisenberg kernel: BTRFS info (device dm-0): scrub: not finished on devid 1 with status: -5
>
>
>
>> For memory bitflip, since it's corrupted in memory, the checksum will
>> be
>> calculated using the corrupted data, thus the checksum for that tree
>> block will be correct, thus scrub won't detect it.
>
> I though that would depend on where/when the bitflip happens... i.e. if
> it happens on either the data or the csum, after the latter has been
> calculated but before both are written.
>
>
>
>> The problem is not in the file data, but that checksum tree block.
>>
>> Unfortunately there will be no good way to reset that bitflip using
>> btrfs-check.
>>
>> It's possible to manually reset that generation and re-calculate the
>> csum to fix the fs.
>>
>> But it needs to be done manually, as no tool has taken bitflip into
>> consideration.
>
> So how to do it then?
>
> If I could determine which files are all affected and if it was e.g.
> just that one,... would deleting it help (assuming that this would also
> clear the broken part of the checksum tree)?

No common operations can help.

But I can craft you a special fix to manually reset the generation of
that offending csum tree block, as a last resort method.

>
> And if not... how can  recover? Recursively copying all files to a
> fresh fs would also fail, I guess.
>
>
> And is there a way to read the content of the file while ignoring the
> csum errro?

We have a way, since v5.11, we have a new mount option,
rescue=idatacsums, which can do exactly that, completely ignore data csums.

Thanks,
Qu

>
>
> Thanks,
> Chris.