All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Alberto Alonso <alberto@ggsys.net>
Cc: Doug Ledford <dledford@redhat.com>,
	Samuel Tardieu <sam@rfc1149.net>,
	linux-raid@vger.kernel.org
Subject: Re: Implementing low level timeouts within MD
Date: Thu, 01 Nov 2007 10:14:04 -0400	[thread overview]
Message-ID: <4729DF2C.4020309@tmr.com> (raw)
In-Reply-To: <1193893689.3649.19.camel@w100>

Alberto Alonso wrote:
> On Tue, 2007-10-30 at 13:39 -0400, Doug Ledford wrote:
>   
>> Really, you've only been bitten by three so far.  Serverworks PATA
>> (which I tend to agree with the other person, I would probably chock
>>     
>
> 3 types of bugs is too many, it basically affected all my customers
> with  multi-terabyte arrays. Heck, we can also oversimplify things and 
> say that it is really just one type and define everything as kernel type
> problems (or as some other kernel used to say... general protection
> error).
>
> I am sorry for not having hundreds of RAID servers from which to draw
> statistical analysis. As I have clearly stated in the past I am trying
> to come up with a list of known combinations that work. I think my
> data points are worth something to some people, specially those 
> considering SATA drives and software RAID for their file servers. If
> you don't consider them important for you that's fine, but please don't
> belittle them just because they don't match your needs.
>
>   
>> this up to Serverworks, not PATA), USB storage, and SATA (the SATA stack
>> is arranged similar to the SCSI stack with a core library that all the
>> drivers use, and then hardware dependent driver modules...I suspect that
>> since you got bit on three different hardware versions that you were in
>> fact hitting a core library bug, but that's just a suspicion and I could
>> well be wrong).  What you haven't tried is any of the SCSI/SAS/FC stuff,
>> and generally that's what I've always used and had good things to say
>> about.  I've only used SATA for my home systems or workstations, not any
>> production servers.
>>     
>
> The USB array was never meant to be a full production system, just to 
> buy some time until the budget was allocated to buy a real array. Having
> said that, the raid code is written to withstand the USB disks getting
> disconnected as far as the driver reports it properly. Since it doesn't,
> I consider it another case that shows when not to use software RAID
> thinking that it will work.
>
> As for SCSI I think it is a greatly proved and reliable technology, I've
> dealt with it extensively and have always had great results. I know deal
> with it mostly on non Linux based systems. But I don't think it is
> affordable to most SMBs that need multi-terabyte arrays.
>   
Actually, SCSI can fail as well. Until recently I was running servers 
with multi-TB arrays, and regularly, several times a year, a drive would 
fail and glitch the SCSI bus such that the next i/o to another drive 
would fail. And I've had SATA drives fail cleanly on small machines, so 
neither is an "always" config.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


  reply	other threads:[~2007-11-01 14:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 17:12 Implementing low level timeouts within MD Alberto Alonso
2007-10-26 19:00 ` Doug Ledford
2007-10-27 10:33   ` Samuel Tardieu
2007-10-30  5:19     ` Alberto Alonso
2007-10-30 17:39       ` Doug Ledford
2007-11-01  5:08         ` Alberto Alonso
2007-11-01 14:14           ` Bill Davidsen [this message]
2007-11-01 19:16           ` Doug Ledford
2007-11-02  8:41             ` Alberto Alonso
2007-11-02 11:09               ` David Greaves
2007-11-02 17:47                 ` Alberto Alonso
2007-11-02 12:44               ` Bill Davidsen
2007-11-02 15:45               ` Doug Ledford
2007-11-02 18:21                 ` Alberto Alonso
2007-11-02 19:15                   ` Doug Ledford
2007-11-02 21:24                     ` Alberto Alonso
2007-10-27 21:46   ` Alberto Alonso
2007-10-27 23:55     ` Doug Ledford
2007-10-28  6:27       ` Alberto Alonso
2007-10-29 17:22         ` Doug Ledford
2007-10-30  5:08           ` Alberto Alonso
2007-10-30 12:12             ` Gabor Gombas
2007-10-30 17:58             ` Doug Ledford
2007-11-01 14:19             ` Bill Davidsen
2007-11-07  8:47           ` Goswin von Brederlow
2007-10-27 18:59 ` Richard Scobie
     [not found]   ` <1193522726.7690.31.camel@w100>
2007-10-27 23:46     ` Richard Scobie
2007-10-30  4:47 ` Neil Brown

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=4729DF2C.4020309@tmr.com \
    --to=davidsen@tmr.com \
    --cc=alberto@ggsys.net \
    --cc=dledford@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=sam@rfc1149.net \
    /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.