From: Kai Krakow <hurikhan77+btrfs@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: WARNING: at fs/btrfs/extent-tree.c:4754 followed by BUG: unable to handle kernel NULL pointer dereference at (null)
Date: Thu, 15 Dec 2011 05:11:04 +0100 [thread overview]
Message-ID: <sj8or8-fqk.ln1@hurikhan.ath.cx> (raw)
In-Reply-To: 4EE0DFEB.2000904@jan-o-sch.net
Hello,
I managed to mount my broken btrfs partition in read-only mode and clone my
rootfs subvolume to an ext4 partition and boot from that - so I now have the
original system bootable.
Jan Schmidt wrote:
> On 07.12.2011 21:40, Kai Krakow wrote:
[...]
>> The problematic file seems to be in /usr/portage but scrubbing doesn't
>> tell me the filename (I was under the impression 3.2.x adds a patch which
>> should report filenames).
>
> It should. Did you take a look at dmesg output after scrubbing? If it
> doesn't contain a hint on the file or block, please paste what you get.
[ 187.136485] device fsid 311dda08-f33f-4cb9-9d59-6eac6026b1b1 devid 2
transid 146954 /dev/sda3
[ 187.136776] btrfs: use lzo compression
[ 187.136777] btrfs: disk space caching is enabled
[ 190.874110] zcache: created ephemeral tmem pool, id=2, client=65535
[ 243.659298] checksum error at logical 622147694592 on dev /dev/sda3,
sector 301624: metadata leaf (level 0) in tree 2
[ 243.659302] checksum error at logical 622147694592 on dev /dev/sda3,
sector 301624: metadata leaf (level 0) in tree 2
[ 243.725126] btrfs: unable to fixup (regular) error at logical
622147694592
[ 306.023952] parent transid verify failed on 622147694592 wanted 130733
found 134506
[ 306.023960] parent transid verify failed on 622147694592 wanted 130733
found 134506
[ 306.023963] parent transid verify failed on 622147694592 wanted 130733
found 134506
[ 306.023966] parent transid verify failed on 622147694592 wanted 130733
found 134506
[ 306.023968] parent transid verify failed on 622147694592 wanted 130733
found 134506
Here's the last scrub status:
scrub status for 311dda08-f33f-4cb9-9d59-6eac6026b1b1
scrub started at Sat Dec 10 10:34:57 2011 and was aborted after 2711
seconds
total bytes scrubbed: 318.77GB with 3 errors
error details: read=1 verify=2
corrected errors: 0, uncorrectable errors: 1, unverified errors: 0
I'm not sure what "read" and "verify" mean in this context.
This happens with 3.2.0-rc4... I'm switching to rc5 soon. But as you (@Jan)
can see: No file pathes are printed.
Regards,
Kai
prev parent reply other threads:[~2011-12-15 4:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 20:40 WARNING: at fs/btrfs/extent-tree.c:4754 followed by BUG: unable to handle kernel NULL pointer dereference at (null) Kai Krakow
2011-12-08 16:03 ` Jan Schmidt
2011-12-09 13:34 ` Kai Krakow
2011-12-15 4:11 ` Kai Krakow [this message]
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=sj8or8-fqk.ln1@hurikhan.ath.cx \
--to=hurikhan77+btrfs@gmail.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).