All of lore.kernel.org
 help / color / mirror / Atom feed
From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: Software RAID5 with 2.6.0-test
Date: 21 Oct 2003 21:36:39 GMT	[thread overview]
Message-ID: <bn48t7$j8s$1@gatekeeper.tmr.com> (raw)
In-Reply-To: yw1xu167kbcw.fsf@users.sourceforge.net

In article <yw1xu167kbcw.fsf@users.sourceforge.net>,
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@users.sourceforge.net> wrote:
| Bill Davidsen <davidsen@tmr.com> writes:
| 
| >> However, I wouln't count on superior performance from software based
| >> RAID 5 (ata/fakeraid or otherwise), that is whats real raid controllers
| >> are for.
| >
| > While an overloaded system may benefit from offloaded the CPU
| > requirements of RAID, unless you go to a very expensive external unit
| > the kernel RAID will usually outperform the inexpensive RAID embedded on
| > a controller. The kernel simply knows more about the data needs and can
| > can do things a controller can't.
| 
| What about the RAID controllers in the $400 category?  Surely, they
| must be doing something better than the $50 fakeraid controllers.

Unfortunately my experience is with either the cheap motherboard ones I
get for free and the IBM ServRAID controllers which are kind of in the
"more than that" category. The benefit of the m/b ones is that with
RAID-1 you will get a boot if the boot drive fails. Period. Unlike
optimal RAID-1 which will read mirrored data from any non-busy drive,
the cheap ones seem to do fail-over only, and read the second drive
only if the first fails, or even require both drives to be on the same
cable, ensuring that the bus will be busy when either drive is busy.
They do buy reliability, however, so there are places where they are
very cost effective.

The IBM controllers are everything you ever wanted in a controller. It
supports four SCSI busses for bandwidth, all the RAID types including
5e, and it has Linux config software so you can do most reconfigures on
a running system. I would choose them over anything else I've personally
used, mainly Adaptec and PERC. They are really great for multi-TB
storage systems.

But in between is where software RAID wins. In many medium
applications, the limit isn't CPU, and it isn't bus bandwidth, it's the
base speed of the disk access counted as either access time or
bandwidth depending on the application. So the major benefits of
midprice RAID for ATAPI/SATA aren't realized, performance is the issue.

It's obvious that the o/s has information which a RAID controller
doesn't in terms of ordering i/o. And similarly true that adding a GB to
the main system is going to help overall more than a GB on a controller
(as noted, 256MB seems the limit on some), because the o/s will use it
more effectively for buffers, and because it will eliminate some i/o
entirely, particularly swap. And nothing speeds a disk operation more
than avoiding the need to do it.

Anyone who says that any one solution is best for everything is clearly
misguided, but I do think that for many midsize applications that
software RAID is the most cost effective solution, and vs. moderately
priced controllers very likely to be the higher performance solution as
well.

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

  parent reply	other threads:[~2003-10-21 21:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 22:43 Software RAID5 with 2.6.0-test Måns Rullgård
2003-10-08 23:24 ` Torrey Hoffman
2003-10-08 23:44   ` Måns Rullgård
2003-10-09  0:51     ` Andre Tomt
2003-10-09  8:55       ` Måns Rullgård
2003-10-09  9:10         ` Andre Tomt
2003-10-09  9:28           ` Måns Rullgård
2003-10-17 17:07           ` Bill Davidsen
2003-10-17 17:44             ` Måns Rullgård
2003-10-17 18:39               ` Samuel Flory
2003-10-17 19:18                 ` Måns Rullgård
2003-10-17 19:37                   ` Jakob Oestergaard
2003-10-17 19:52                     ` Måns Rullgård
2003-10-18 22:55                   ` jw schultz
2003-10-17 19:24               ` Jakob Oestergaard
2003-10-19  9:25                 ` Pavel Machek
2003-10-21 21:44                 ` bill davidsen
2003-10-21 21:36               ` bill davidsen [this message]
2003-10-22 15:17                 ` Chuck Campbell
2003-10-18 11:50 Dr. David Alan Gilbert
2003-10-21 21:51 ` bill davidsen
2003-10-22  2:37   ` jw schultz

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='bn48t7$j8s$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@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.