I prefer SW to HW raid as well. It runs on generic HW (controllers), so
there's nothing special to replace. Finding a replacement HW raid card
can be difficult, especially if it's an older card.
Charles Jones wrote:
> Glad to help. In a way I sort of like software RAID better than hardware
> RAID, because of workarounds like this. I've had a 3ware hardware raid
> card fail, and there was nothing I could do until I snagged another
> 3ware card from ebay. I also had an old promise raid card drop 2
> drives at once, but there was no option to force the array back together
> without a rebuild. I have so far been lucky enough to recover from
> multi-drive failures every time when using software RAID. As far as
> performance, I benchmarked a server we have that has a 12 disk software
> RAID5, and it got the highest IO of any server I had tested, and that
> was with crappy ATA-133 PATA drives. I also experience lots of problems
> with those darn Dell PERC raid controllers - they seem to like to flake
> out for no reason.
>
> Joe Fleming wrote:
>> You're my savior man! I found a post on some forum talking about using
>> mdadm --examine to check the superblock on the drives. /dev/sdc1 was a
>> complete no show, but /dev/sdd1 (which was also failed) looked ok,
>> though outdated. I deactivated the array with mdadm --stop /dev/md0
>> and forced an assemble with the command you gave me.
>>
>> mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdd1
>>
>> And I'm back online! Time to copy files off ASAP. I still hear the
>> chirping noise, from one of the drives, but at least it's back up.
>> Thanks again!
>>
>> -Joe
>>
>> Charles Jones wrote:
>>> Joe Fleming wrote:
>>>> Hey all, I have a Debian box that was acting as a 4 drive RAID-5
>>>> mdadm softraid server. I heard one of the drives making strange
>>>> noises but mdstat reported no problems with any of the drives. I
>>>> decided to copy the data off the array so I had a backup before I
>>>> tried to figure out which drive it was. Unfortunately, in the middle
>>>> of copying said data, 2 of the drives dropped out at the same time.
>>>> Since RAID-5 is only tolerant to one failure at a time, basically
>>>> the whole array is hosed now. I've had drives drop out on me before,
>>>> but never 2 at once. Sigh.
>>>>
>>>> I tried to Google a little about dealing with multi-drive failures
>>>> with mdadm, but I couldn't find much in my initial looking. I'm
>>>> going to keep digging, but I thought I'd post a question to the
>>>> group and see what happens. So, is there a way to tell mdadm to
>>>> "unmark" one of the 2 drives as failed and try to bring up the array
>>>> again WITHOUT rebuilding it? I really don't think both of the drives
>>>> failed on me simultaneously and I'd like to try to return 1 of the 2
>>>> to the array and test my theory. If I can get the array back up, I
>>>> can either keep trying to copy data off it or add a new replacement
>>>> and try to rebuild. I'm pretty novice with mdadm thought I don't see
>>>> an option that will let me do what I want. Can anyone offer me some
>>>> advice or point me in the right direction..... or am I just SOL?
>>>>
>>>> As a side note, why can't hard drive manufacturers make drives that
>>>> last anymore? I've had like 5 drives fail on me in the last year...
>>>> WD, Seagate, Hitachi, they all suck equally! I can't find any that
>>>> last for any reasonable amount of time, and all the warranties leave
>>>> you with reman'd drives which fail even more rapidly, some even show
>>>> up DOA. Plus, I'm not sending my unencrypted data off to some random
>>>> place! Sorry for venting, just a little ticked off at all of this.
>>>> Thanks in advance for any help.
>>>>
>>>> -Joe
>>>
>>> I've had luck in the past recovering from a multi-drive failure,
>>> where the other failed drive was not truly dead but rather was
>>> dropped because of an IO error caused by a thermal calibration or
>>> something similar. The trick is to re-add the drive to the array and
>>> using the option to force it NOT to try to rebuild the array. This
>>> used to be an require several options like --really-force and
>>> --really-dangerous but now I think its just something like --assemble
>>> --force /dev/md0. This forces the array to come back up to its
>>> degraded (still down 1 disk) state. If possible replace the degraded
>>> disk or copy your data off before the other flakey drive fails.
>
--
-Eric 'shubes'
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)