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

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

On 2022/7/9 09:34, Denis Roy wrote:
> 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

This can vary from very complex or even impossible (if your NAS has a
very rare setup, like using some rare archtecture/boot sequence) to as
simple as installing a distro (like debian or ubuntu).

If your NAS is an x86/x86_64 based system, then it may be much easier,
just try to find how to go into the BIOS, change the boot sequence and
try boot from LiveCD of your choice.


Otherwise, it will be a long long journey to find out a distro
supporting your device.

Thanks,
Qu
>
> 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