From: Jakob Oestergaard <jakob@unthought.net>
To: Chris Meadors <clubneon@hereintown.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Panic when finishing raidreconf on 2.4.0-test4 with preempt
Date: Tue, 9 Sep 2003 20:11:32 +0200 [thread overview]
Message-ID: <20030909181131.GB9079@unthought.net> (raw)
In-Reply-To: <1062883950.1341.26.camel@clubneon.clubneon.com>
On Sat, Sep 06, 2003 at 05:32:30PM -0400, Chris Meadors wrote:
> I've done this twice now, I'd prefer not to do it again, but can upon
> request, if you really need the oops output.
>
> Running raidreconf to expand a 4 disk array to 5, seems to work
> correctly until the very end. I'm guessing it is as the RAID super
> block is being written. A preempt error is triggered and the kernel
> panics. Upon reboot the MD driver doesn't think the 5th disk is valid
> for consideration in the array and skips over it. Leaving a very
> corrupted file system.
raidreconf does no "funny business" with the kernel, so I think this
points to either:
*) a bug which mkraid can trigger as well
*) an API change combined with missing error handling, which raidreconf
now triggers (by calling the old API)
*) a more general kernel bug - there is a *massive* VM load when
raidreconf does its magic, perhaps calling mkraid after beating
the VM half way to death can trigger the same error?
raidreconf, upon complete reconfiguration, will set up the new
superblock for you array, mark it as "unclean", and add the disks one by
one. Once all disks are added, the kernel should start calculating
parity information (because raidreconf does not do this during the
conversion, and hence marks the newly set up array as unclean in order
to have the kernel do this dirty work).
There should be nothing special about this, compared to normal mkraid
and raidhotadd usage - except raidreconf is probably a lot more likely
to trigger races.
Ah, fingerpointing ;)
(/me sits back, confident that his code is perfect and the kernel alone
is to blame)
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
next prev parent reply other threads:[~2003-09-09 18:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-06 21:32 Panic when finishing raidreconf on 2.4.0-test4 with preempt Chris Meadors
2003-09-09 18:11 ` Jakob Oestergaard [this message]
2003-09-09 19:21 ` Chris Meadors
2003-09-09 20:42 ` Jakob Oestergaard
2003-09-12 7:16 ` Panic when finishing raidreconf on 2.6.0-test4 " Chris Meadors
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=20030909181131.GB9079@unthought.net \
--to=jakob@unthought.net \
--cc=clubneon@hereintown.net \
--cc=linux-kernel@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