linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Martin <monkeyiq@users.sourceforge.net>
To: Michal Soltys <soltys@ziu.info>
Cc: linux-raid@vger.kernel.org, Ben Martin <monkeyiq@users.sourceforge.net>
Subject: Re: Benchmarks: Linux Kernel RAID vs a Hardware RAID setup
Date: Wed, 16 Jul 2008 13:36:32 +1000	[thread overview]
Message-ID: <1216179392.5633.348.camel@sam.localdomain> (raw)
In-Reply-To: <487CC660.9030004@ziu.info>

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On Tue, 2008-07-15 at 17:46 +0200, Michal Soltys wrote:
> Ben Martin wrote:
> > Hi,
> >   Apologies if posting this here is inappropriate but a recent article
> > of mine compares the Linux Kernel RAID code to an $800 hardware RAID
> > card and might be of interest to list members:
> > 
> > http://www.linux.com/feature/140734
> > 
> 
> Very interesting. Btw - did you use stripe-width on ext3s as well, or 
> only stride ?

Only stride unfortunately. After digging through this ML's archives the
stride was mentioned a lot but not stripe-width. I still have some
reserved partitions across the RAID for future benchmarks and
verification so I'll whip up a comparison of using stripe-width vs not
using it at some stage (ah, free time).

Perhaps this page could use some love with append(stripe-width).
http://linux-raid.osdl.org/index.php/RAID_setup#Options_for_mke2fs


> 
> Also looking back at other benchmarks, stripe_cache_size can have pretty 
> tremendous effect on md raid performance. There're other settings that 
> could matter as well (read ahead, queue depths). It would be interesting 
> to see e.g. raid5 256k chunk comparison, done with those altered ( 
> _especially_ md's stripe_cache_size with some high value like 16384 or 
> 32768), and with stripe-width used in ext3 case (if it wasn't used already).

I have been meaning to ask for a while, why is the stripe_cache_size
set so low by default if it has such an effect on performance? 

Obviously being conservative by default is less likely to get the kernel
devs into trouble, but perhaps having the system realize that the system
has 8gb of RAM and two RAID-$whatever setups in /etc/mdadm.conf and
using some simple dynamic algorithm to figure out that for this amount
of system RAM and two RAIDs of type $whatever it should chomp up say
256Mb of RAM for each RAID and turn read ahead on for each mdadm device.

I'm not sure if each individual Linux distro cares enough about this to
hack up their boot time scripts to do it.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2008-07-16  3:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15 14:06 Benchmarks: Linux Kernel RAID vs a Hardware RAID setup Ben Martin
2008-07-15 14:42 ` Justin Piszcz
2008-07-16  4:14   ` Ben Martin
2008-07-15 15:46 ` Michal Soltys
2008-07-15 20:34   ` Richard Scobie
2008-07-16  2:34     ` Mr. James W. Laferriere
2008-07-16  2:48       ` Richard Scobie
2008-07-16  2:52         ` Mr. James W. Laferriere
2008-07-16  4:17           ` Keld Jørn Simonsen
2008-07-16  5:50       ` Michal Soltys
2008-07-16  3:36   ` Ben Martin [this message]
2008-07-16  3:55     ` Richard Scobie
2008-07-16  7:00       ` Dan Williams
2008-07-16 17:08       ` thomas62186218
2008-07-16 19:34         ` Richard Scobie
2008-07-15 16:39 ` Keld Jørn Simonsen
2008-07-15 16:50   ` thomas62186218
2008-07-15 17:39     ` Keld Jørn Simonsen
2008-07-16  0:01       ` Richard Scobie
2008-07-16  0:20         ` Jon Nelson
2008-07-16  4:06           ` Ben Martin
2008-07-16 15:42           ` Ben Martin
2008-07-16  4:23         ` Keld Jørn Simonsen
2008-07-16  5:18           ` Richard Scobie
2008-07-16  8:17             ` Keld Jørn Simonsen
2008-07-15 17:06   ` Jon Nelson
2008-07-16  3:44     ` Ben Martin
2008-07-15 18:40   ` Brad Campbell
2008-07-15 20:12     ` Keld Jørn Simonsen
2008-07-21 16:55       ` Bill Davidsen
2008-07-23  7:45         ` Keld Jørn Simonsen
2008-07-23 10:29           ` Brad Campbell
     [not found]     ` <487CF499.6080105@harddata.com>
2008-07-15 20:15       ` Keld Jørn Simonsen
2008-07-16  3:58   ` Ben Martin
2008-07-16  4:47     ` Keld Jørn Simonsen
2008-07-21 16:58       ` Bill Davidsen
2008-07-15 19:41 ` Keld Jørn Simonsen
2008-07-16  3:25   ` Ben Martin
2008-07-15 20:40 ` Peter Grandi
2008-07-16  3:38 ` Eric Sandeen
2008-07-16 18:54 ` Alan D. Brunelle
2008-07-17  8:26   ` Ben Martin

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=1216179392.5633.348.camel@sam.localdomain \
    --to=monkeyiq@users.sourceforge.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=soltys@ziu.info \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).