All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert L Mathews <lists@tigertech.com>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: RAID 1 failure on single disk causes disk subsystem to lock up
Date: Wed, 02 Apr 2008 11:33:23 -0700	[thread overview]
Message-ID: <47F3D173.8060502@tigertech.com> (raw)
In-Reply-To: <18417.16752.269484.583258@tree.ty.sabi.co.uk>

Peter Grandi wrote:

 > If you have high availability requirements perhaps you should buy
 > from an established storage vendor a storage system designed by
 > integration engineers and guaranteed by the vendor for some high
 > availability level.

Actually, I don't trust such systems. That's our main reason for using 
software RAID 1: if all else fails with regard to RAID, we can take one 
of the disks and mount it as a non-RAID ext3 file system. No 
"guaranteed" proprietary system can offer that.

(And other than this one perplexing problem, we've been extremely happy 
with software RAID for many years -- thanks, Neal and everyone else 
involved.)


 > Perhaps without realizing it you have engaged in storage system
 > design and integration and there are many, many, many, many subtle
 > pitfalls in that (as the archives of this list show abundantly).
 >
 > You cannot just slap things together and it all works. Have you
 > done even sketchy common mode failure analysis?

Ouch!  :-)

Just for the record, this isn't "slapped together" hardware. They're 
off-the-shelf, server-grade, currently sold, genuine Intel, etc. 
SuperMicro servers, with no modifications, specifically chosen because 
they're widely used. The only storage system design we've done is 
connect a SATA drive to each of the two motherboard SATA ports and use 
software RAID 1 (yeah, I know that's "design", and we did think about it 
and test it, but still).

We've done many stress/failure tests for data storage, all of which pass 
as expected. What I unfortunately can't test in advance is how they 
behave when a working hard disk suddenly has a mechanical failure, which 
is the only time we've seen a problem.

I could sacrifice a working disk by opening it up while running and 
poking the platters with a screwdriver (I've seriously considered this), 
but repeating the test more than a few times would get expensive.


 > Also putting two drives belonging to a RAID set on the same
 > IDE/ATA channel is usually a bad idea for performance too.

They're SATA drives. There's no actual IDE hardware involved.

-- 
Robert L Mathews

  parent reply	other threads:[~2008-04-02 18:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-30 23:22 RAID 1 failure on single disk causes disk subsystem to lock up Robert L Mathews
2008-03-31 10:01 ` Justin Piszcz
2008-03-31 17:30   ` Robert L Mathews
2008-03-31 19:12     ` Justin Piszcz
     [not found] ` <47F0281F.1070404@harddata.com>
2008-03-31 17:27   ` Robert L Mathews
2008-03-31 19:54     ` Peter Grandi
2008-04-01 19:33       ` Richard Scobie
2008-04-02 18:33       ` Robert L Mathews [this message]
2008-04-03 21:01         ` Peter Grandi
2008-04-04 19:11           ` Robert L Mathews
2008-04-02 17:43 ` Bill Davidsen
2008-04-02 18:42   ` Robert L Mathews

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=47F3D173.8060502@tigertech.com \
    --to=lists@tigertech.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.