[lug] RAID installation on Fedora 6 Zod

Kevin Fenzi kevin at scrye.com
Fri May 11 13:28:23 MDT 2007


On Fri, 11 May 2007 11:20:15 -0400 (EDT)
steve at badcheese.com wrote:

> By flakey when talking about linux's software raid is when a drive
> fails. Since the IDE controller (underneath the software raid) isn't
> raid-aware, if a drive fails, you'll get timeouts and your machine
> will be either super-slow or hang due to HD I/O.  The IDE controller
> will give those DMA timeouts and keep trying to read/write to the
> drive when it's failing. If you pull the bad drive and reboot, then
> linux will be happy and operate in degraded-mode and be ok, just
> needs some manual intervention.  That's mainly what I meant by flakey.

Odd. I have never seen this behavior with linux software raid. 

When a drive gets an error, linux notices, removes the drive from the
raid, and disables I/O to that drive and continues in degraded mode. 
I don't think the IDE controller needs to be aware of anything. The
kernel just simply stops sending any I/O to the dead drive...

> 
> With hardware raid, the drive failure is detected (on our LSI
> controllers, we made a nagios plugin to detect a degraded RAID
> partition, so we get a notification), it's marked as failed and the
> RAID goes about its business in degraded mode until maintenance is
> performed with no perceived impact on performance to the user.

In the cases where I have had linux software raid have drive failures,
this has always been my experience with it. 

> - Steve

kevin
--
> On Thu, 10 May 2007, Sean Reifschneider wrote:
> 
> > Date: Thu, 10 May 2007 21:54:37 -0600
> > From: Sean Reifschneider <jafo at tummy.com>
> > Reply-To: "Boulder (Colorado) Linux Users Group -- General Mailing
> > List" <lug at lug.boulder.co.us>
> > To: "Boulder (Colorado) Linux Users Group -- General Mailing List"
> >     <lug at lug.boulder.co.us>
> > Subject: Re: [lug] RAID installation on Fedora 6 Zod
> > 
> > On Wed, May 09, 2007 at 10:42:08AM -0400, steve at badcheese.com wrote:
> >> I know that the Linux software raid can be a little flakey, but in
> >> my
> >
> > Flaky?  How so?  For our hosting customers doing RAID-1 on 2 discs,
> > we recommend doing Linux software RAID.  It's been EXTREMELY
> > reliable for us. Performance is great, overhead is not noticable,
> > and tools to interact with and manage it are fantastic.  Software
> > RAID is pretty much the only option that installs a tool to alert
> > you to a drive failure as a standard part of the OS install.
> >
> > The most important part of a RAID install is, of course, making
> > sure you get alerted when the first drive fails.  Because you
> > *WILL* get alerted when the second drive fails, and you won't be
> > happy.
> >
> > And a hardware RAID controller is no guarantee of fewer bugs or more
> > performance.  For example, the highest end 3ware RAID cards do not
> > interleave RAID-10 reads across both drive pairs...  RAID 0 and 1
> > do not involve any computation overhead, so offloading to hardware
> > doesn't help as much as RAID-5.  And there can be other more subtle
> > problems with hardware RAID, like not properly committing the
> > changes to disc before removing them from the battery backed RAM.
> > Read the livejournal outage report when they lost power last year
> > for more information about these problems.
> >
> > I'd recommend you do a new install and use the RAID setup in the
> > installer. You can do it after the fact, but if you don't already
> > know how to do it I'd guess you aren't quite ready to be doing it.
> > As far as slapping a hardware RAID controller, you need to know if
> > the controller stores data on the drive (being invasive) or not.
> > If it is invasive, you can't just have it RAID the existing drive.
> > Again, you probably just want to do a re-install.
> >
> > Sean
> >
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20070511/e3b34ffd/attachment.pgp>


More information about the LUG mailing list