linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Denis Roy <denisjroy@gmail.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: Thu, 7 Jul 2022 18:56:24 +0200	[thread overview]
Message-ID: <20220707165623.GI15169@twin.jikos.cz> (raw)
In-Reply-To: <3ed7ee56-24fe-4fe6-b9ec-857adc8924cf@gmx.com>

On Thu, Jul 07, 2022 at 10:19:53AM +0800, Qu Wenruo wrote:
> 
> 
> On 2022/7/7 09:32, Denis Roy wrote:
> > I am using netgate readynas firmware 6.10.7, 5 drives ,X-RAID.  I had a
> > power failure, but the nas never did a full shutdown. Nevertheless, the
> > raid was in RO when I notice there was a problem. At the time I thought
> > it was plex app, so I rebooted and then the raid never cam up.  Ever
> > where you read up on BTRFS, they say don’t try commands you can do more
> > dameage. So here I am. I added some info I believe you need and if there
> > anything else, let me know.
> 
> That error message means, a tree node is pointing to a location which is
> not aligned to sectorsize (the minimal unit of btrfs read/write).
> 
> But there are several problems:
> 
> - The bytenr 12567101254720864896, is aligned to 4096
>    A quick python run shows:
>    >>> 12567101254720864896 / 4096.0
>    3068139954765836.0

You should not rely on floats but do either hex() or '% 4096', because
both show that the value is not aligned to 4096:

  >>> hex(12567101254720864896)
  '0xae6750020000c280L'

the expected pattern is 3 trailing zeros of the value, or

  >>> 12567101254720864896 % 4096
  640L

The hex value does not resemble any pattern, more data from the physical
block could tell more if it's completely random or eg. leftover from
other memory or overwrite.

The block offset checks are done after checksum verification so the data
were corrupted and then written, ie. it happened before the write.

  reply	other threads:[~2022-07-07 17: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 [this message]
2022-07-08  5:50     ` Denis Roy
2022-07-08  6:00       ` Qu Wenruo
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=20220707165623.GI15169@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=denisjroy@gmail.com \
    --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).