All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Hardy <mhardy@h3c.com>
To: Harry Mangalam <hjm@tacgi.com>, linux-raid@vger.kernel.org
Subject: Re: More tales of horror from the linux (HW) raid crypt
Date: Wed, 22 Jun 2005 12:33:10 -0700	[thread overview]
Message-ID: <42B9BCF6.1010206@h3c.com> (raw)
In-Reply-To: <200506201853.11768.hjm@tacgi.com>


Not that I wish bad luck on anyone, but I always enjoy reading about
problems others have had and how they solved them, so I don't have to
learn the hard way. Hopefully your situation gets sorted out.

I can only second (and third, etc) the motion to do SMART tests on all
drives before putting them in service, and add that you should really do
a short test daily and a long test at least weekly if possibly.
Basically you just can't trust consumer drives at all these days.
smartmontools and rsync are probably my most-loved open source packages
these days. I usually get 1 out of 10 bad out of the box now (some
remappable at least) and a handful then fail quickly too. Most of them
haven't gone three years so I can't say if they fail completely, but
they seem to be lasting ok with occasional bad blocks.

I'm very interested in the relative SW raid / HW raid performance. I
have both in service (two raid 5 sets are actually the same size with
the same number of components) and see roughly the same as you mention.
One difference that I see is that HW raid should generate fewer
interrupts and lower bus traffic.

In the one area I used HW raid (a 3ware 8 port PATA, 8x250GB Maxtor,
2xOpteron), it was specifically because the motherboard chipset (or its
interaction with Linux at least) was crap, and couldn't handle the
interrupt load under bonnie++. So this could be a factor.

It also goes to show that burning the machine in (with bonnie++ or
similar) is a very good step. At least you catch these things before
they're in service...

Anyway, good luck with the new drives.

-Mike

Harry Mangalam wrote:
> Hi All,
> 
>>From the traffic, this list seems to be heavily slanted towards the SW aspect 
> of Linux RAID, but there have been a few postings (other than mine) about the 
> HW aspects of it.  So, apologies for the verbarea on the HW aspects, but at 
> least a few people have told me that this running monologue of raid troubles 
> has been useful, so herein, some more.  If I'm reiterating what is part of a 
> FAQ, please let me know, but I read a lot of them and didn't stumble across 
> much of this.
> 
> 
> short version:  test ALL your disks before you use them, especially in a RAID 
> set, especially the 'recertified' ones.

  reply	other threads:[~2005-06-22 19:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-18 11:47 when does it become faulty disk Raz Ben-Jehuda(caro)
2005-06-19 19:10 ` Molle Bestefich
2005-06-20  6:43   ` raz ben jehuda
2005-06-20  7:55     ` Molle Bestefich
2005-06-20 10:09       ` raz ben jehuda
2005-06-20 13:45   ` Michael Tokarev
2005-06-20 15:35     ` raz ben jehuda
2005-06-21  1:53 ` More tales of horror from the linux (HW) raid crypt Harry Mangalam
2005-06-22 19:33   ` Mike Hardy [this message]
2005-06-22 20:16     ` Harry Mangalam
2005-06-22 20:38       ` Jure Pecar
2005-06-22 21:33         ` Harry Mangalam
2005-06-22 23:15           ` SMART, was " Konstantin Olchanski
2005-06-22 23:32             ` Harry Mangalam
2005-06-22 23:35             ` Mike Hardy
2005-06-22 21:09       ` Brad Dameron
2005-06-22 21:43         ` Harry Mangalam
2005-06-22 22:00           ` Ming Zhang
2005-06-22 22:11             ` John Madden
2005-06-22 22:26               ` Ming Zhang
2005-06-23  0:20               ` bdameron
2005-06-22 22:45             ` Harry Mangalam
2005-06-22 23:05               ` Ming Zhang
2005-06-23  0:25               ` bdameron
2005-06-23  0:14             ` bdameron
2005-06-23  0:49               ` Ming Zhang
2005-06-23  3:05                 ` Guy
2005-06-23 12:31                   ` Ming Zhang
2005-06-23 13:03                     ` Guy
2005-06-23 13:17                       ` Andy Smith
2005-06-23 13:19                       ` Ming Zhang
2005-06-22 23:54       ` Jon Lewis
2005-06-22 20:54     ` Dan Stromberg
2005-06-22 21:15       ` Brad Dameron

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=42B9BCF6.1010206@h3c.com \
    --to=mhardy@h3c.com \
    --cc=hjm@tacgi.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.