Re: Errors found in extent allocation tree (single bit flipped)

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

在 2024/8/27 08:34, Pieter P 写道:
> Thanks for the help!
>
> On 21/08/2024 00:55, Qu Wenruo wrote:
>
>> And in that case, "btrfs check --mode=lowmem" output may help a little
>> more, and the same for "btrfs check --repair --mode=lowmem".
>
> I've attached the output from both commands, unfortunately, that didn't
> fix the issue.
>
> Subvolume 257 is my /home directory, and the broken inode is a temporary
> file in a Chromium cache folder. I've tried deleting and overwriting
> that file, but this causes the file system to go read-only a couple of
> seconds later, and after re-mounting, the file re-appears. Reading the
> file is not possible (input/output error).
>
> Is there a way to restore the file system by simply deleting this
> inode+data entirely?

After your latest --repair try, the fs should be more or less fine, you
can try remove the offending file.

Just a minor problem left with the superblock used bytes, that can be
fixed by another "btrfs check --repair" run very safely.

>
>> If above lowmem mode still doesn't work, I can craft a tool for your
>> specific corruption if really needed.
>>
>> But that will need the dump of your subvolume 257 inode 50058751.
>
> Which data would you need specifically? How do I get such a dump?

No need anymore, the latest result contains the all the info I need.

>
>> Unless the system is using ECC memories, I doubt if that diagnostic tool
>> makes any difference.
>>
>> If there is already a strong indication of bitflip (and yes, it is), a
>> full memtest is highly recommended.
>
> No ECC memory, but I did perform the "thorough" memory test using the
> Dell diagnostic tool multiple times. It included data bus stress tests,
> march C- tests, ground bounce tests, random pattern tests, and some
> others; all passed without issues. Since I haven't noticed any other
> problems (the system works fine when booting from another drive), I'm
> blaming an unfortunate cosmic ray for now :)

Unfortunately it's indeed a bitflip, from your latest lowmem repair
result (which mostly solves the problem).

 > ERROR: extent[2216718336, 4096] referencer count mismatch (root: 257,
owner: 50058751, offset: 0) wanted: 1, have: 0

This is the original extent item, which looks sane to me.

 > Add one extent data backref [576460754520141824 4096]

This is the one to be added according to the subvoluem tree. The huge
value itself is already a little concerning.

Furthermore:

hex(576460754520141824) = 0x800000084207000
hex(2216718336)         = 0x000000084207000

It's an obvious bitflip.

Another possibility is, the fs is old and you just migrated the drive/fs
to the current platform, but I doubt about the case considering the file
is some browser cache, which shouldn't be that old.

Just in case, mind to try something like memtest86+ (UEFI payload) or
memtester (inside the OS) to rule out the hardware problem?

Hope it's really a cosmic ray, not a persistent hardware problem.

Thanks,
Qu
>
> Thank you!
> Pieter