Linux RAID subsystem development
 help / color / mirror / Atom feed
From: James Ralston <qralston+ml.linux-raid@andrew.cmu.edu>
To: Neil Brown <neilb@cse.unsw.edu.au>,
	"Cress, Andrew R" <andrew.r.cress@intel.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Question about recovery via mdadm
Date: Sun, 16 Feb 2003 05:32:20 -0500	[thread overview]
Message-ID: <28330000.1045391539@shieldbreaker.l33tskillz.org> (raw)
In-Reply-To: <15948.9979.534439.238616@notabene.cse.unsw.edu.au>

On 2003-02-14 at 10:15:07+1100 Neil Brown <neilb@cse.unsw.edu.au> wrote:

> On Thursday February 13, andrew.r.cress@intel.com wrote:
> 
> > Solving why I got into this is another issue, but: Is there any
> > way, once I'm in this predicament, to force a recovery to the
> > spare, from userland (via mdadm)?
> 
> No.  Reconstrution should start automatically.  There is no
> mechanism to start it from user-space.  You could try to hot-remove
> and hot-add again, but if it didn't work the first time it is
> unlikely to work the second time.
> 
> It would appear to be a kernel bug.  Are there any kernel messages?
> An Oops or something?

I'll bet that if Andrew checks his syslog carefully, he'll find that
the mdrecovery process generated a kernel Oops:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82815

If this is what happened, then simply rebooting the system should
cause the reconstruction to start.

> Do you know if redhat:2.4.18-14 contains any patches particular to
> md?

I doubt that's the problem, as I tried backporting the vanilla md
driver from 2.4.21-pre3 into Red Hat's kernel-2.4.18-19.8.0, and I
could still Oops it.

IMHO, the two most likely explanations are:

    1.  There's a bug in the md driver somewhere.

    2.  Red Hat has tweaked/changed something in the kernel that the
        md driver is relying on, and as a result, what the md driver
        is doing causes an Oops.

Neil, if you want to try to track this down, I'll be happy to help in
any way I can.  (I don't have enough kernel hacking experience to
track this down myself, alas.)

Regards,

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA


  reply	other threads:[~2003-02-16 10:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13 15:43 Question about recovery via mdadm Cress, Andrew R
2003-02-13 23:15 ` Neil Brown
2003-02-16 10:32   ` James Ralston [this message]
2003-02-16 22:09     ` Neil Brown
2003-02-17  1:05       ` James Ralston
2003-02-18  5:45         ` Neil Brown
  -- strict thread matches above, loose matches on Subject: below --
2003-02-17 15:59 Cress, Andrew R

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=28330000.1045391539@shieldbreaker.l33tskillz.org \
    --to=qralston+ml.linux-raid@andrew.cmu.edu \
    --cc=andrew.r.cress@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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