linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).