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
next prev 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.