From: Mike Myers <mikesm559@yahoo.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: linux-raid@vger.kernel.org, john lists <john4lists@gmail.com>
Subject: Re: Need urgent help in fixing raid5 array
Date: Fri, 2 Jan 2009 20:19:40 -0800 (PST) [thread overview]
Message-ID: <480194.8807.qm@web30808.mail.mud.yahoo.com> (raw)
In-Reply-To: alpine.DEB.1.10.0901021355370.3485@p34.internal.lan
Ok, good news and bad news. I finally got all the disks connected and bypassed the backplane. Md2 starts with 6 members in a degraded mode. Md1 is still having the same problem. In doing an examine on each member disk, I discovered that 8 disks had the superblock referencing md2's UUID. The other thing is that only 6 had the UUID of md1, which is suppposed to have 7 members. One of the two (sdf1) that has the superblock of md2 (but not active in the array) is also an Hitachi, which it shouldn't be (md2 is a seagate 7200.11 array). This appears to be the missing md1 disk. I don't understand how it got the other raid array's info, but things are weird here.
That was the good news. The bad news is that when I tried to assemble md1 with all the md1 members plus sdf1 (the disk that thinks its part of md2), I mistakenly used it as the target for for mdadm assemble command. Ugh.
So I typed: mdadm /dev/sdf1 --assemble /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdi1 /dev/sdj1 --force
So now sdf1 instead of having the wrong superblock has no super block. Am I completely hosed at this point? I probably needed to figure out a way to get this disk a new superblock anyway, but but I suspect things are even harder to fix at this point.
Any ideas as to how to fix this? Is there another superblock somewhere else on the disk that I can recover the proper info from?
Thanks,
mike
----- Original Message ----
From: Justin Piszcz <jpiszcz@lucidpixels.com>
To: Mike Myers <mikesm559@yahoo.com>
Cc: linux-raid@vger.kernel.org; john lists <john4lists@gmail.com>
Sent: Friday, January 2, 2009 10:57:13 AM
Subject: Re: Need urgent help in fixing raid5 array
On Fri, 2 Jan 2009, Mike Myers wrote:
> Well, I can read from sdg1 just fine. It seems to work ok, at least for a few GB of data. I'll try this on some of the other disks, but it is possible for to pull the disks out of the backplane and run the SFF-8087 fanout cables direct to each drive and bypass the backplane completely. It certainly would be easy to do this for the at least the sdo1 drive and see if I can get better results going direct to the disk. I have moved the disks around the backplane a bit to deal with the issues of the controller failure, so I am pretty sure it's not just one bad slot or the like.
>
> So you've seen a backplane fail in away that the disks come up fine at boot but have corrupted data transfers across them? I wonder about the sata cables in that case as well. I could hook up a pair of PMP's to my SI3132's and bypass the 8077 cables as well.
1. Try by-passing the backplane.
2. Bad cables will usually cause smart identifier UDMA_CRC_Error_Count to
increase quite high, if it is 0 or close to it, the cable is unlikely the
issue.
3. I have seem all kinds of weirdness with bad backplanes, drives dropping out
of the array, drives producing I/O errors, etc.
Justin.
next prev parent reply other threads:[~2009-01-03 4:19 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <451872.61166.qm@web30802.mail.mud.yahoo.com>
2009-01-01 15:40 ` Need urgent help in fixing raid5 array Justin Piszcz
2009-01-01 17:51 ` Mike Myers
2009-01-01 18:29 ` Justin Piszcz
2009-01-01 18:40 ` Jon Nelson
2009-01-01 20:38 ` Mike Myers
2009-01-02 6:19 ` Mike Myers
2009-01-02 12:10 ` Justin Piszcz
2009-01-02 18:12 ` Mike Myers
2009-01-02 18:22 ` Justin Piszcz
2009-01-02 18:46 ` Mike Myers
2009-01-02 18:57 ` Justin Piszcz
2009-01-02 20:46 ` Mike Myers
2009-01-02 20:56 ` Mike Myers
2009-01-02 21:37 ` Mike Myers
2009-01-03 4:19 ` Mike Myers [this message]
2009-01-03 4:43 ` Guy Watkins
2009-01-03 5:02 ` Mike Myers
2009-01-03 12:46 ` John Robinson
2009-01-03 15:49 ` Mike Myers
2009-01-03 16:14 ` John Robinson
2009-01-03 16:47 ` Mike Myers
2009-01-03 19:03 ` Mike Myers
2009-01-05 22:11 ` Neil Brown
2009-01-05 22:22 ` Mike Myers
2009-01-05 22:53 ` NeilBrown
2009-01-06 2:46 ` Mike Myers
2009-01-06 4:00 ` NeilBrown
2009-01-06 5:55 ` Mike Myers
2009-01-06 23:23 ` Neil Brown
2009-01-06 6:24 ` Mike Myers
2009-01-06 23:31 ` Neil Brown
2009-01-06 23:54 ` Mike Myers
2009-01-07 0:19 ` NeilBrown
2009-01-13 5:38 ` Mike Myers
2009-01-13 5:57 ` Mike Myers
2009-01-01 15:31 Mike Myers
-- strict thread matches above, loose matches on Subject: below --
2008-12-05 17:03 Mike Myers
2008-12-06 0:18 ` Mike Myers
2008-12-06 0:24 ` Justin Piszcz
2008-12-06 0:47 ` Mike Myers
2008-12-06 0:51 ` Justin Piszcz
2008-12-06 0:58 ` Mike Myers
2008-12-06 19:02 ` Mike Myers
2008-12-06 19:30 ` Mike Myers
2008-12-06 20:14 ` Mike Myers
2008-12-06 0:52 ` David Lethe
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=480194.8807.qm@web30808.mail.mud.yahoo.com \
--to=mikesm559@yahoo.com \
--cc=john4lists@gmail.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-raid@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.