From: Bill Davidsen <davidsen@tmr.com>
To: Gordon Henderson <gordon@drogon.net>
Cc: Adam Kropelin <akropel1@rochester.rr.com>,
Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: Linux: Why software RAID?
Date: Mon, 04 Sep 2006 13:29:22 -0400 [thread overview]
Message-ID: <44FC6272.9000403@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.56.0608241438360.6721@lion.drogon.net>
Gordon Henderson wrote:
>On Thu, 24 Aug 2006, Adam Kropelin wrote:
>
>
>
>>>Generally speaking the channels on onboard ATA are independant with any
>>>vaguely modern card.
>>>
>>>
>>Ahh, I did not know that. Does this apply to master/slave connections on
>>the same PATA cable as well? I know zero about PATA, but I assumed from
>>the terminology that master and slave needed to cooperate rather closely.
>>
>>
>
>I don't know much about co-operation between master & slave, but I do know
>that a failing PATA IDE drive can take out the other one on the same bus -
>or in my case, render it unusable until I removed the dead drive,
>whereupon (to my relief) it sprang back into life.
>
>This was many many moons ago before I started to use s/w RAID, but it's
>one thing that would kill a multi-disk array, so I've never done it since.
>
>I guess the same could happen on SCSI, but I suspect the interface is a
>little better designed...
>
Until recently I was working with 38 systems using SCSI RAID controllers
(IBM ServeRAID Ultra320). With several types of SCSI drives I saw
failures where one drive failed, hung the bus, and caused the next
command to another drive to fail. At that point I have to force the
controller to think the 2nd drive failed was okay, and then it would
recover. I'm told this happens with other hardware, I just haven't
personally seen it.
From that standpoint, the SATA on the MB look pretty good!
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2006-09-04 17:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 3:34 Linux: Why software RAID? Jeff Garzik
2006-08-24 4:22 ` Richard Scobie
2006-08-24 8:19 ` Jeff Garzik
2006-08-24 20:08 ` Richard Scobie
2006-08-24 5:20 ` Chris Friesen
2006-08-24 5:25 ` H. Peter Anvin
2006-08-26 20:55 ` Dan Williams
2006-08-24 5:43 ` Mattias Wadenstein
2006-08-24 13:07 ` Adam Kropelin
2006-08-24 13:20 ` Alan Cox
2006-08-24 13:36 ` Adam Kropelin
2006-08-24 13:42 ` Gordon Henderson
2006-09-04 17:29 ` Bill Davidsen [this message]
2006-08-24 14:55 ` Mark Lord
[not found] ` <44EDB843.2020608@perkel.com>
2006-08-24 15:21 ` Alan Cox
2006-09-04 17:31 ` Bill Davidsen
2006-09-04 17:31 ` Joel Jaeggli
-- strict thread matches above, loose matches on Subject: below --
2006-08-26 3:50 linux
2006-08-26 12:18 ` Raz Ben-Jehuda(caro)
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=44FC6272.9000403@tmr.com \
--to=davidsen@tmr.com \
--cc=akropel1@rochester.rr.com \
--cc=gordon@drogon.net \
--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 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).