linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Lange <john.lange@bighostbox.com>
To: Guy <bugzilla@watkins-home.com>
Cc: 'LinuxRaid' <linux-raid@vger.kernel.org>
Subject: RE: Please review: Slackware RAID How-To
Date: Thu, 20 May 2004 02:58:56 -0500	[thread overview]
Message-ID: <1085039936.10231.74.camel@localhost> (raw)
In-Reply-To: <200405200502.i4K52rB18138@www.watkins-home.com>

Hey Guy. Thanks very much for your research.

Since we couldn't seem to come up with a definitive answer I decided to
resort to some tests. I have a little RAID 5 array comprised of 3 8G
SCSI disks in a old Dell PowerEdge (same box mentioned in the How-To).

Just for reference here is it's raidtab:

raiddev /dev/md0
raid-level      5
nr-raid-disks   3
nr-spare-disks  0
chunk-size      32
persistent-superblock 1
parity-algorithm        left-symmetric
device          /dev/sdb1
raid-disk       0
device          /dev/sdc1
raid-disk       1
device          /dev/sdd1
raid-disk       2

I used mke2fs to format the drive in 3 different ways with variable
stride settings then ran bonnie++ on it.

The settings were:

stride=64
stride=4
stride=512

The first two are based on the different formulas we discussed. I tried
512 just because I thought I'd do something a bit crazy to see if it
made any difference.

The results in bonnie++ were almost statistically identical in every
case. The only difference in performance was a 20% drop in random seeks
when stride=512 but the rest of the performance indicators were almost
identical. I repeated the test to make sure it wasn't a blip.

So the bottom line is; for me, neither chunk-size OR stride makes any
difference to performance.

John Lange

On Thu, 2004-05-20 at 00:02, Guy wrote:
> More info!
> 
> I found this comment in another group.  It would indicate "stripe size"
> should be used.  But it should not make a difference.
> 
> Guy
> 
> =======================================================================
> The stride option places the inode and block bitmaps so that successive
> block groups' bitmaps are on a different RAID stripes.  I suppose this
> might improve disk I/O performance, as the bitmaps are the most heavily 
> used blocks on the disk.  However, the cache should prevent most of the
> I/O in the first place...
> 
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of John Lange
> Sent: Wednesday, May 19, 2004 11:34 PM
> To: office@ninti.com.au
> Cc: LinuxRaid
> Subject: RE: Please review: Slackware RAID How-To
> 
> No, stride is not needed for RAID 1 as stride is about striping and RAID
> 1 does not do striping, it does mirroring.
> 
> According to man raidtab, chunk-size "Sets the stripe size to size
> kilobytes.". So unless I'm completely off my rocker, chunk-size is also
> not needed for RAID 1 as it also only applies to striping.
> 
> Thanks for pointing that out. I have removed it from my HowTo.
> 
> I believe this error is also in the Software RAID HowTo which is where I
> copied my examples from.
> 
> Regards,


  reply	other threads:[~2004-05-20  7:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-11 15:42 Please review: Slackware RAID How-To John Lange
2004-05-11 23:51 ` Ninti Systems
2004-05-16  5:43 ` Ninti Systems
2004-05-16  6:40 ` Ninti Systems
2004-05-17  2:36 ` Ninti Systems
2004-05-17  4:51   ` Guy
2004-05-17  9:02     ` Ninti Systems
2004-05-20  1:42     ` John Lange
2004-05-20  2:06       ` Ninti Systems
2004-05-20  3:27         ` Guy
2004-05-20  3:33         ` John Lange
2004-05-20  5:02           ` Guy
2004-05-20  7:58             ` John Lange [this message]
2004-05-20 13:37               ` Guy
2004-05-21  2:25               ` Ninti Systems
2004-05-21  2:55                 ` Guy
2004-05-21  2:47               ` Ninti Systems
2004-05-20  3:11       ` Guy
2004-05-20  4:35         ` Guy
  -- strict thread matches above, loose matches on Subject: below --
2004-05-13  9:46 George  Iosif
2004-05-14  6:21 George  Iosif
     [not found] <s0a48f9e.018@nsa.ase.ro>
2004-05-14  6:47 ` John Lange

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=1085039936.10231.74.camel@localhost \
    --to=john.lange@bighostbox.com \
    --cc=bugzilla@watkins-home.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 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).