On 12/1/23 14:09, Qu Wenruo wrote:
> 
> 
> On 2023/12/1 22:16, Russell Haley wrote:
>> Distro: Fedora 39
>> kernel: 6.5.12
>> btrfs-progs: v6.5.1.
>>
>> To put everyone at ease, the data seems mostly okay. The disk is
>> mountable with ro,rescue=ingorebadroots:nologreplay, and I'm pulling off
>> what I can.  Furthermore, there's a good chance this is the result of a
>> marginally-unstable overclock. However, the symptoms are very similar to
>> a recent report from Alexander Duscheleit [1], so there may be a deeper
>> problem. I can provide requested metadata dumps if it would be useful,
>> and I also have a few questions.
>>
>> A few days ago I used btrfstune to convert two btrfs filesystems to
>> block-group-tree, after reading that it would reduce mount time. After
>> about 10 hours, while I was using Steam, the more heavily-used of the
>> two disks, which holds (among other things) the Steam game library,
>> experienced a transaction abort and went read-only.
> 
> Any dmesg of that transaction abort? That's the most critical info here.

[80343.530191] BTRFS error (device dm-1): parent transid verify failed
on logical 31850496 mirror 1 wanted 123883 found 123907
[80343.587776] BTRFS error (device dm-1): parent transid verify failed
on logical 31850496 mirror 2 wanted 123883 found 123907
[80343.587836] BTRFS error (device dm-1): failed to run delayed ref for
logical 916815872 num_bytes 16384 type 176 action 1 ref_mod 1: -5
[80343.587844] BTRFS error (device dm-1: state A): Transaction aborted
(error -5)
[80343.587846] BTRFS: error (device dm-1: state A) in
btrfs_run_delayed_refs:2182: errno=-5 IO failure

>> 2. There's something extremely weird with the primary superblock. "btrfs
>>     inspect-internal dump-super" says that superblock 0 doesn't have the
>>     BLOCK_GROUP_TREE or NO_HOLES flags set, unlike superblocks 1 and 2,
>>     which are identical in every field except csum ("[match]", for 0, 1,
>>     and 2) and bytenr.
> 
> This is not good at all, if csum of super blocks doesn't match, there
> must be something especially wrong.

Comparing to other btrfs disks I have access to, different checksum for
the backup superblocks seems normal? It does say [match] after the
checksum value. Just the value itself is different.

I dumped the 3 superblocks with btrfs inspect-internal dump-super -f and
attached them to this message. "Meld" for 3-way diff worked well for me.

Thanks for your help,

  Russell Haley