From: Justin Chudgar <justin@justinzane.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfsck segmentation fault
Date: Sat, 08 Jan 2011 17:11:48 -0800 [thread overview]
Message-ID: <4D290B54.3000204@justinzane.com> (raw)
In-Reply-To: <AANLkTinwUx6JZZ8mJLU1C=EYiu_RgBSNzoEucCyoWBWd@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've got the same problem. That is, I have a 2.6.35 btrfs volume that
segfaults and causes a kernel oops upon attempts to mount it. There is
some data on there that was not covered by the daily backup. Though it
is not the end of the world, I'd like to recover it if possible. If
there are absolutely no recovery options, a note on the wiki about
which failures are nonrecoverable might be good.
Thanks for the continuous improvements.
*Justin Chudgar* - Weed, CA 96094
On 01/08/2011 03:42 AM, Fajar A. Nugraha wrote:
> On Sat, Jan 8, 2011 at 5:29 AM, cwillu <cwillu@cwillu.com> wrote:
>> On Fri, Jan 7, 2011 at 3:15 PM, Andrew Schretter
<schrett@math.duke.edu> wrote:
>>> I have a 10TB btrfs filesystem over iSCSI that is currently
unmountable. I'm
>>> currently running Fedora 13 with a recent Fedora 14 kernel
(2.6.35.9-64.fc14.i686.PAE)
>>> and the system hung with messages like :
>>>
>>> parent transid verify failed on 5937615339520 wanted 48547 found 48542
>>>
>>> I've rebooted and and am attempting to recover with btrfsck from the
btrfs-progs-unstable
>>> git tree, but it is segfaulting after finding a superblock and
listing out 3 of the
>>> "parent transid" messages. Anyone have any ideas?
>>>
>>> I tried btrfsck /dev/sdb, btrfsck -s 1 /dev/sdb, and btrfsck -s 2
/dev/sdb with the
>>> same result for each. The btrfsck binary I compiled does work on a
small (800MB) test
>>> btrfs file system. I suspect it may be due to the size of the
filesystem I am trying
>>> to repair.
>> Segfaulting is what the current btrfsck does when it finds a problem;
>> it doesn't try to fix anything yet.
> Is there something we can do to fix this particular problem (e.g.
> editing the metadata manually to use older transaction group), or is
> this one of those forhet-in-you're-screwed kind of thing?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0pC0kACgkQUl5UaPAPOwJrMACdFGRSKrw4H56mlG26Tys4hYL/
iiYAn1YNOoUaUvSJz7TB+IwX17V9XfiX
=8vhU
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-01-09 1:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 21:15 btrfsck segmentation fault Andrew Schretter
2011-01-07 22:29 ` cwillu
2011-01-08 11:42 ` Fajar A. Nugraha
2011-01-09 1:11 ` Justin Chudgar [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-01-17 1:27 André Goddard Rosa
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=4D290B54.3000204@justinzane.com \
--to=justin@justinzane.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).