From: Denis Roy <denisjroy@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
linux-btrfs@vger.kernel.org
Subject: Re: BTRFS critical (device md126): corrupt node: root=1 block=13404298215424 slot=307, unaligned pointer, have 12567101254720864896 should be aligned to 4096
Date: Fri, 8 Jul 2022 02:20:14 -0400 [thread overview]
Message-ID: <BD6F70A8-17FB-40E3-87DE-E185049DEA2E@gmail.com> (raw)
In-Reply-To: <1d43c273-5af3-6968-de18-d70a346b51aa@suse.com>
Ok, great. How do I do that?
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
next prev parent reply other threads:[~2022-07-08 6:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 1:32 BTRFS critical (device md126): corrupt node: root=1 block=13404298215424 slot=307, unaligned pointer, have 12567101254720864896 should be aligned to 4096 Denis Roy
2022-07-07 2:19 ` Qu Wenruo
2022-07-07 16:56 ` David Sterba
2022-07-08 5:50 ` Denis Roy
2022-07-08 6:00 ` Qu Wenruo
2022-07-08 6:20 ` Denis Roy [this message]
2022-07-08 7:04 ` Qu Wenruo
2022-07-09 1:34 ` Denis Roy
2022-07-09 1:48 ` Qu Wenruo
2022-07-09 1:53 ` Denis Roy
2022-07-07 19:56 ` Denis Roy
2022-07-09 2:16 ` Denis Roy
2022-07-09 2:18 ` Qu Wenruo
2022-07-09 2:20 ` Denis Roy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BD6F70A8-17FB-40E3-87DE-E185049DEA2E@gmail.com \
--to=denisjroy@gmail.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).