From: Zheng Liu <gnehzuil.liu@gmail.com>
To: semenko@syndetics.net
Cc: Tomasz Chmielewski <mangoo@wpkg.org>,
linux-ext4@vger.kernel.org, semenko@alum.mit.edu, tytso@mit.edu,
djwong@us.ibm.com
Subject: Re: "Unknown code" error when enabling metadata_csum on ext4 raid1 device
Date: Thu, 2 Aug 2012 17:58:19 +0800 [thread overview]
Message-ID: <20120802095818.GA4651@gmail.com> (raw)
In-Reply-To: <CAFepXZjgihKhAOpF3KJ8dKfHGpip-Kaf8+xvwrpTOqWB8Zs9rQ@mail.gmail.com>
On Wed, Aug 01, 2012 at 10:43:05PM -0500, Nick Semenkovich wrote:
[-- snip --]
> Sorry for the slow reply --
>
>
> I hadn't seen any "Corrupt dir inode" errors until now.
>
> Before running the one-line patch above, I resynced the MD array and
> ran a quick fsck (via "touch /forcefsck" & reboot).
>
>
> Then,
> $ sudo misc/tune2fs -O metadata_csum /dev/md1
>
> [says something about running e2fsck -D]
>
>
> Then I got a few dmesg errors like:
>
> [128700.816091] JBD2: Spotted dirty metadata buffer (dev = md1,
> blocknr = 5243385). There's a risk of filesystem corruption in case of
> system crash.
> [128700.816106] JBD2: Spotted dirty metadata buffer (dev = md1,
> blocknr = 1057). There's a risk of filesystem corruption in case of
> system crash.
>
> then a lot of
>
> [128711.000677] EXT4-fs warning (device md1): dx_probe:647: dx entry:
> limit != root limit
> [128711.000679] EXT4-fs warning (device md1): dx_probe:732: Corrupt
> dir inode 7733251, running e2fsck is recommended.
>
>
> On my next command (sudo -s), I got an immediate kernel panic:
>
> [128713.776475] EXT4-fs warning (device md1): dx_probe:732: Corrupt
> dir inode 7733251, running e2fsck is recommended.
> [128761.137143] BUG: unable to handle kernel NULL pointer dereference
> at (null)
> [128761.137195] IP: [<ffffffff8121d448>] ext4_iget+0x498/0xa50
> [128761.137231] PGD 106651067 PUD 11cf41067 PMD 0
> [128761.137258] Oops: 0000 [#1] SMP
> [128761.137279] CPU 0
> [snip...]
>
> Full panic @ http://web.mit.edu/semenko/Public/panic.txt
Hi Nick,
Thanks for testing my patch. As you described above, it seems that
there still has some bugs when metadata_csum feature enabled. I tried
to reproduce this bug, but I couldn't reproduce it in my sandbox. I see
the full panic file, and it seems that the kernel is running on Ubuntu
distribution and it doesn't use a generic mainline kernel. So IMHO
would you like to try a latest upstream kernel? At least when the
problem happens again, it is easy for me to find out where goes wrong.
Thanks for your patient.
Regards,
Zheng
next prev parent reply other threads:[~2012-08-02 9:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 2:53 "Unknown code" error when enabling metadata_csum on ext4 raid1 device Nick Semenkovich
2012-08-01 7:19 ` Zheng Liu
2012-08-01 7:16 ` Tomasz Chmielewski
2012-08-01 7:48 ` Zheng Liu
2012-08-01 7:51 ` Tomasz Chmielewski
2012-08-01 8:17 ` Zheng Liu
2012-08-02 3:43 ` Nick Semenkovich
2012-08-02 9:58 ` Zheng Liu [this message]
2012-08-03 4:01 ` Theodore Ts'o
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=20120802095818.GA4651@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=djwong@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=mangoo@wpkg.org \
--cc=semenko@alum.mit.edu \
--cc=semenko@syndetics.net \
--cc=tytso@mit.edu \
/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).