From: Shane Shrybman <shrybman@teksavvy.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Oops while rebalancing, now unmountable.
Date: Tue, 09 Nov 2010 13:21:32 -0500 [thread overview]
Message-ID: <1289326892.4231.2.camel@mars> (raw)
In-Reply-To: <1289310046-sup-839@think>
On Tue, 2010-11-09 at 08:42 -0500, Chris Mason wrote:
> Excerpts from Shane Shrybman's message of 2010-11-08 12:10:57 -0500:
> > Hi,
> >
> > Got an oops last week while rebalancing that seems to have left me with
> > a corrupted btrfs. Kernel was ~2.6.36 + Transparent hugetlb patchset +
> > small misc. patchs.
>
> We have a confirmed and reproducible case where the transparent
> hugepages are corrupting btrfs (and only btrfs). I'll work with Andrea
> on figuring out the cause.
>
> So, the first step to trying to fix it is to grab the latest btrfsck and
> see if some old copies of the super are working:
>
> btrfsck -s 1 /dev/xxx
> btrfsck -s 2 /dev/xxx
>
Yeah, I tried that with the latest btrfsck (last commit was:
btrfs-debug-tree: add -d option ...)
# ./btrfsck -s 1 /dev/sdc1
using SB copy 1, bytenr 67108864
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
Segmentation fault
# ./btrfsck -s 0 /dev/sdc1
using SB copy 0, bytenr 65536
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
Segmentation fault
# ./btrfsck -s 2 /dev/sdc1
using SB copy 2, bytenr 274877906944
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
checksum verify failed on 625055924224 wanted C3DFFE41 found FFFFFF88
Segmentation fault
# ./btrfsck -s 3 /dev/sdc1
using SB copy 3, bytenr 1125899906842624
No valid Btrfs found on /dev/sdc1
Hmm, odd that btrfsck -s 0 /dev/sdc1 finds a different checksum than
before.
next prev parent reply other threads:[~2010-11-09 18:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 17:10 Oops while rebalancing, now unmountable Shane Shrybman
2010-11-08 17:55 ` Chris Mason
2010-11-08 20:39 ` Shane Shrybman
2010-11-08 21:04 ` Chris Mason
2010-11-08 21:25 ` Shane Shrybman
2010-11-09 13:42 ` Chris Mason
2010-11-09 18:21 ` Shane Shrybman [this message]
2010-11-14 19:55 ` Shane Shrybman
2010-11-14 20:42 ` Andrea Arcangeli
2010-11-14 22:00 ` Christoph Hellwig
2010-11-14 22:12 ` Andrea Arcangeli
2010-11-15 18:23 ` Christoph Hellwig
2010-11-15 18:46 ` Chris Mason
2010-11-15 19:03 ` Christoph Hellwig
2010-11-16 21:48 ` Shane Shrybman
2010-11-15 18:46 ` Andrea Arcangeli
2010-11-15 19:03 ` Chris Mason
2010-11-15 19:16 ` Andrea Arcangeli
2010-11-15 19:12 ` Christoph Hellwig
2010-11-15 19:18 ` Chris Mason
2010-11-15 19:29 ` Andrea Arcangeli
2010-11-15 20:54 ` Christoph Hellwig
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=1289326892.4231.2.camel@mars \
--to=shrybman@teksavvy.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
/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).