Re: BTRFS critical (device md126): corrupt node: root=1 block=13404298215424 slot=307, unaligned pointer, have 12567101254720864896 should be aligned to 4096

[Denis Roy <denisjroy@gmail.com>]

Love to comply to run the latest version, but I past from my 
experiences. Maybe you could help me on update/upgrading so I can do the 
check. I trying to learn here, need some help

On 2022-07-08 3:04 a.m., Qu Wenruo wrote:
>
>
> On 2022/7/8 14:20, Denis Roy wrote:
>> Ok, great. How do I do that?
>
> Considering you're using a vendor specific firmware/hardware, I don't
> have any good suggestion, other than upgrade to the latest version the
> vendor provides, and hope they upgraded the kernel.
>
> Or you may want to jump into the rabbit hole of running a common distro
> on the NAS hardware so that you have full control of the system, but
> lose all the out-of-box experience provided by those NAS vendors.
>
>
> For the corrupted fs, you may want to run btrfs check (latest version
> recommended) and post it.
> Then we may be able to decide if the fs can be repaired properly.
>
> Thanks,
> Qu
>>
>> Sent from my iPhone
>>
>>> On Jul 8, 2022, at 2:01 AM, Qu Wenruo <wqu@suse.com> wrote:
>>>
>>> 
>>>
>>>> On 2022/7/8 13:50, Denis Roy wrote:
>>>>      key (7652251795456 EXTENT_ITEM 72057594063093760) block 
>>>> 12567101254720864896 (383517494345729) gen 72340209471334675
>>>>      key (2959901138859622420 EXTENT_CSUM 3664676558733568) block 
>>>> 2234066886193184768 (68178310735876) gen 18374696375462128179
>>>>      key (1153765929541501184 EXTENT_CSUM 0) block 0 (0) gen 0
>>>>      key (0 UNKNOWN.0 0) block 0 (0) gen 0
>>>
>>> The above dump shows the tree node is completely corrupted by some 
>>> weird data.
>>>
>>> The offending slot is not aligned, and its offset (extent size for 
>>> EXTENT_ITEM) is definitely not correct.
>>>
>>> But the offset looks like a bitflip:
>>>
>>> hex(72057594063093760) = '0x100000001800000'
>>>
>>> Ignoring the high bit, 0x1800000 is completely sane for the size of 
>>> an data extent.
>>>
>>> The next slot even has incorrect type, (EXTENT_CSUM) should not 
>>> occur in
>>> extent tree, but this time I can not find a pattern in the corrupted 
>>> type.
>>>
>>> The offset, 3664676558733568, is also not aligned but without a 
>>> solid corruption pattern.
>>>
>>> And finally we have an UNKNOWN key, which should not occur there at 
>>> all.
>>>
>>>
>>> So this looks like that tree node is by somehow screwed up in the 
>>> middle.
>>> I don't have any clue how this could happen, but considering the 
>>> checksum still passed, it must happen at runtime.
>>>
>>>
>>> For now, I can only recommend to go kernel newer than 5.11 which 
>>> introduced mandatory write-time tree block sanity check, and should 
>>> reject such bad tree block before it can be written to disk.
>>>
>>> Thanks,
>>> Qu