linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Denis Roy <denisjroy@gmail.com>,
	dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
	"linux-btrfs@vger.kernel.org" <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 14:00:51 +0800	[thread overview]
Message-ID: <1d43c273-5af3-6968-de18-d70a346b51aa@suse.com> (raw)
In-Reply-To: <70241659-fa66-0b65-0efe-1a426d05dcb4@gmail.com>



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

  reply	other threads:[~2022-07-08  6:01 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 [this message]
2022-07-08  6:20         ` Denis Roy
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=1d43c273-5af3-6968-de18-d70a346b51aa@suse.com \
    --to=wqu@suse.com \
    --cc=denisjroy@gmail.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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).