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:32, Christoph Anton Mitterer wrote:
> And I still don't understand this:
>
>
> 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
>
> You say the damage is in the csum tree... is that checksummed itself
> (and the error is noticed just by reading the block in the tree)... or
> is it noticed when the (actual data) is compared to the (wrong) data in
> the ckecksum tree and the mismatch is detected.

Btrfs handles checksum differently for metadata (tree block) and data.

For metadata, its header has 32 bytes reserved for checksum, and that's
where the csum of metadata is.
Aka, inlined checksum.

For data, we put data checksum into its own tree, aka the csum tree.
It records the logical -> data checksum mapping.

Currently, if btrfs has any thing wrong searching csum tree, it will not
even submit the data read.

>
>
>> thus
>> unable to verify a lot of data.
>
> How much is a lot? I copied the whole fs before, when I made the
> backup,.. and I got errors only for that 1382301696 and that one
> file... all others, tar read without giving any error.
> Is that exepcted?nd out which files are affected by that part of
the checksum tre

It really depends.

For the worst case, if the generation mismatch happens at a very high
level, the whole csum tree can be rendered useless.
In that case, almost all data can be affected (although the data on-disk
may still be OK).

For the best case, it's just a leave got this corruption.
In that case, if you're using SHA256 and 16K nodesize, you get at most
2MiB range which can not be read.
(Again, on disk data can still be fine)

>
>
>
>
>> 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.
>
> Could that part of the checksum block have been rewritten recently?

Depends on the generation. If your current generation (can be checked
with btrfs ins dump-super) is close to the number 262166, then it's
possible it's rewritten recently.

Thanks,
Qu

> Cause I send/received that data at least once in the past to another
> fs... and I would have assumed that any error should have shown up
> already back then (didn't however).... so the bitflip must have
> happened recently... after the affected file had been written to disk
> originally (and after it's checksum had been written originally).
>
>
> Thanks,
> Chris.