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 08:38, Christoph Anton Mitterer wrote:
> On Mon, 2022-02-28 at 07:26 +0800, Qu Wenruo wrote:
>> I checked the transid:
>>
>> hex(262166) = 0x40016
>> hex(22)     = 0x00016
>>
>> So definitely a bitflip.
>
> Hmm... would be a surprise, since I copy loads of data over that
> machine, which is always protected by some SHA512 sums.
> But could of course be possible.
>
> I assume you mean the bitflip would have happened when the data was
> written? Cause reading it reproducibly causes the same issue.

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.

>
> But shouldn't a scrub have noticed that?

Please note that, scrub only checks the checksum.

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.

> That file was created around
> January 2019, and since then I've had mad several scrubs at least.
>
>
>> Please run memtest on the machine.
>
> Will do so later.
>
>
>
> Anyway... is it recommended to re-create the fs? Or is deleting the
> file enough, if a fsck+scrub finds nothing else.

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.

Thanks,
Qu

>
>
> Thanks,
> Chris