From: Nate Byrnes <nate@qabal.org>
To: Maurice Hilarius <maurice@harddata.com>
Cc: Nate Byrnes <nate@nemo.qabal.org>, linux-raid@vger.kernel.org
Subject: Re: RAID5 recovery trouble, bd_claim failed?
Date: Wed, 19 Apr 2006 10:20:17 -0400 [thread overview]
Message-ID: <44464721.3080702@qabal.org> (raw)
In-Reply-To: <44464368.2080406@harddata.com>
Hello,
I replaced the failed disk. The configuration is /dev/hde, /dev/hdf
(replaced), on IDE channel 0, /dev/hdg, /dev/hdh on IDE channel 1, on a
single PCI controller card. The issue here is that hde in now also not
accessible after the failure of hdf. I cannot see the jumper configs as
the server is at home, and I am at work. The general thinking was that
the hde superblock got hosed with the loss of hdf.
My initial post only did discuss the disk ordering and device names. As
I had replaced the disk which had failed (in a previously fully
functioning array), with a new disk with exactly the same configuration
(jumpers, cable locations, etc), and each of the disks could be
accessed, my thinking was that there would not be a hardware problem to
sort through. Is this logic flawed?
Thanks again,
Nate
Maurice Hilarius wrote:
> Nate Byrnes wrote:
>
>> Hi All,
>> I'm not sure that is entirely the case. From a hardware
>> perspective, I can access all the disks from the OS, via fdisk and dd.
>> It is really just mdadm that is failing. Would I still need to work
>> the jumper issue?
>> Thanks,
>> Nate
>>
>>
> IF the disks are as we suspect (master and slave relationships) and IF
> you now have either a failed or a removed drive, then you MUST correct
> the jumpering.
> Sure, you can often see a disk that is misconfigured.
> It is almost certain, however, that when you write to it you will simply
> cause corruption on it.
>
> Of course, so far this is all speculation, as you have not actually said
> what the disks, controller interfaces, and jumpering and so forth are at.
> I was merely speculating, based on what you have said.
>
> No amount of software magic will "cure" a hardware problem..
>
>
>
prev parent reply other threads:[~2006-04-19 14:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-15 13:01 RAID5 recovery trouble, bd_claim failed? Nathanial Byrnes
2006-04-16 22:46 ` Neil Brown
2006-04-17 2:54 ` Nathanial Byrnes
2006-04-17 3:04 ` Neil Brown
2006-04-17 10:08 ` Nathanial Byrnes
2006-04-17 10:29 ` Neil Brown
2006-04-17 12:15 ` Nate Byrnes
2006-04-17 19:29 ` Nate Byrnes
2006-04-17 21:43 ` Neil Brown
2006-04-17 22:21 ` Nathanial Byrnes
2006-04-18 0:24 ` Neil Brown
2006-04-18 10:07 ` Nathanial Byrnes
2006-04-18 22:13 ` Maurice Hilarius
2006-04-18 23:39 ` Nathanial Byrnes
2006-04-19 13:41 ` Maurice Hilarius
2006-04-19 13:53 ` Nate Byrnes
2006-04-19 14:04 ` Maurice Hilarius
2006-04-19 14:20 ` Nate Byrnes [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=44464721.3080702@qabal.org \
--to=nate@qabal.org \
--cc=linux-raid@vger.kernel.org \
--cc=maurice@harddata.com \
--cc=nate@nemo.qabal.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).