From: Olivier Bonvalet <btrfs.list@daevel.fr>
To: linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)
Date: Sat, 04 Aug 2012 00:41:59 +0200 [thread overview]
Message-ID: <501C53B7.30601@daevel.fr> (raw)
In-Reply-To: <501AA842.5080300@daevel.fr>
On 02/08/2012 18:18, Olivier Bonvalet wrote:
> On 02/08/2012 15:53, David Sterba wrote:
>> On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote:
>>> Yes... it's a copy from my /var/log/kern.log. Is it really "disabled" ?
>>
>> I was mistaken, it really is enabled unconditionally in ctree.h:55.
>> Josef says that the V0 extent refs are not used for a long time, so the
>> question is how did they appear in your filesystem. Did you switch to a
>> new kernel from a very old one?
>>
>>
>> david
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> mmm I have upgraded that system every two months, but the first setup is from april 2011 I think.
>
> Should I start a "scrub" on all that systems installed a long time ago ?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
So after a hard reboot that filesystem is not mountable anymore :
Aug 4 00:40:06 backup2 kernel: [ 614.826124] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup
Aug 4 00:40:06 backup2 kernel: [ 614.827934] btrfs: force zlib compression
Aug 4 00:40:06 backup2 kernel: [ 614.827943] btrfs: not using ssd allocation scheme
Aug 4 00:40:06 backup2 kernel: [ 614.827950] btrfs: enabling auto recoveryparent transid verify failed on 615015833600 wanted 110423 found 110424
Aug 4 00:40:06 backup2 kernel: [ 614.933613] parent transid verify failed on 615015833600 wanted 110423 found 110424
Aug 4 00:40:06 backup2 kernel: [ 614.934700] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504)
Aug 4 00:40:06 backup2 kernel: [ 614.934716] Failed to read block groups: -5
Aug 4 00:40:07 backup2 kernel: [ 614.952684] btrfs: open_ctree failed
Is there something I can do to fix that ? (the mount option "recovery" didn't help here)
thanks,
Olivier
next prev parent reply other threads:[~2012-08-03 22:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 19:48 kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7) Olivier Bonvalet
2012-08-02 13:22 ` David Sterba
2012-08-02 13:41 ` Olivier Bonvalet
2012-08-02 13:53 ` David Sterba
2012-08-02 16:18 ` Olivier Bonvalet
2012-08-03 22:41 ` Olivier Bonvalet [this message]
2012-08-03 23:30 ` Olivier Bonvalet
2012-08-05 8:57 ` Chris Samuel
2012-08-05 14:11 ` Olivier Bonvalet
2012-08-08 14:45 ` David Sterba
2012-08-08 16:06 ` Stefan Behrens
2012-08-27 8:49 ` Olivier Bonvalet
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=501C53B7.30601@daevel.fr \
--to=btrfs.list@daevel.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.