All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: "Måns Rullgård" <mru@users.sourceforge.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Software RAID5 with 2.6.0-test
Date: Fri, 17 Oct 2003 21:24:19 +0200	[thread overview]
Message-ID: <20031017192419.GG8711@unthought.net> (raw)
In-Reply-To: <yw1xu167kbcw.fsf@users.sourceforge.net>

On Fri, Oct 17, 2003 at 07:44:31PM +0200, Måns Rullgård wrote:
...
> 
> What about the RAID controllers in the $400 category?  Surely, they
> must be doing something better than the $50 fakeraid controllers.

The RAID controllers in the $400 category are exactly the ones who
include (inferior) processors, and add an extra layer in the 'chain of
command'.

The inexpensive 'fakeraid' controllers include some form of SW RAID in
their driver, and could therefore perform as well as Linux SW RAID (if
the driver's RAID code is as clever and efficient as the Linux SW RAID
code - which it may not be).

Ironic, maybe  ;)

I have never tried using one of the 'fakeraid' controllers, so I can't
speak for their actual real-world performance.  They could include a
crap IDE controller, or they could have crap drivers - both could give
poor performance.

Could, would, should, don't know...

However, the "hardware RAID" controllers that were discussed here would
be the ones in the $400->$(obscene) price range.

Now that I'm posting anyway - I thought of a plus for the HW RAID
controllers (hey, they're way behind on the scoreboard so far, so I
might as well be a gentleman and give them a point or two):
*) Battery backed write cache

This will allow the controller to say 'ok I'm done with your sync()',
way before the data actually reaches the disk platters.  For some
workloads this can be a big win.  For some odd reason, it seems that
'most' (read: all that I could find) HW RAID controllers are unable to
control more than 256 MB of memory - which is odd. That amound of memory
is almost so low that it defeats the purpose of having it in the first
place.  But again, some workloads may well benefit.  And this is
something you just can't do with SW RAID (at least not before someone
implements support for an NVRAM buffer store in the Linux I/O layer).

While on that topic: SDRAM PCI cards with battery backup can be had
relatively cheap up to at least a few gigabytes.  It'd be pretty cool to
have the kernel recognize that for buffer storage. I could see the fun
in doing half a million random writes and a sync(), and having the
system tell me it's done the microsecond I issue the sync().

Enough with the daydreaming already  ;)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  parent reply	other threads:[~2003-10-17 19:24 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 [this message]
2003-10-19  9:25                 ` Pavel Machek
2003-10-21 21:44                 ` bill davidsen
2003-10-21 21:36               ` bill davidsen
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=20031017192419.GG8711@unthought.net \
    --to=jakob@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mru@users.sourceforge.net \
    /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.