All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Robin Bowes <robin-lists@robinbowes.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid5 software vs hardware: parity calculations?
Date: Mon, 15 Jan 2007 10:29:10 -0500	[thread overview]
Message-ID: <45AB9DC6.50509@tmr.com> (raw)
In-Reply-To: <eobpl9$df3$1@sea.gmane.org>

Robin Bowes wrote:
> Bill Davidsen wrote:
>   
>> There have been several recent threads on the list regarding software
>> RAID-5 performance. The reference might be updated to reflect the poor
>> write performance of RAID-5 until/unless significant tuning is done.
>> Read that as tuning obscure parameters and throwing a lot of memory into
>> stripe cache. The reasons for hardware RAID should include "performance
>> of RAID-5 writes is usually much better than software RAID-5 with
>> default tuning.
>>     
>
> Could you point me at a source of documentation describing how to
> perform such tuning?
>   
No. There has been a lot of discussion of this topic on this list, and a 
trip through the archives of the last 60 days or so will let you pull 
out a number of tuning tips which allow very good performance. My 
concern was writing large blocks of data, 1MB per write, to RAID-5, and 
didn't involve the overhead of small blocks at all, that leads through 
other code and behavior.

I suppose while it's fresh in my mind I should write a script to rerun 
the whole write test suite and generate some graphs, lists of 
parameters, etc. If you are writing a LOT of data, you may find that 
tuning the dirty_* parameters will result in better system response, 
perhaps at the cost of some small total write throughput, although I 
didn't notice anything significant when I tried them.
> Specifically, I have 8x500GB WD STAT drives on a Supermicro PCI-X 8-port
> SATA card configured as a single RAID6 array (~3TB available space)
>   
No hot spare(s)?

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


  parent reply	other threads:[~2007-01-15 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-11 22:44 raid5 software vs hardware: parity calculations? James Ralston
2007-01-12 17:39 ` dean gaudet
2007-01-12 20:34   ` James Ralston
2007-01-13  9:20     ` Dan Williams
2007-01-13 17:32       ` Bill Davidsen
2007-01-13 23:23         ` Robin Bowes
2007-01-14  3:16           ` dean gaudet
2007-01-15 11:48             ` Michael Tokarev
2007-01-15 15:29           ` Bill Davidsen [this message]
2007-01-15 16:22             ` Robin Bowes
2007-01-15 17:37               ` Bill Davidsen
2007-01-15 21:25               ` dean gaudet
2007-01-15 21:32                 ` Gordon Henderson
2007-01-16  0:35                 ` berk walker
2007-01-16  0:48                   ` dean gaudet
2007-01-16  3:41                     ` Mr. James W. Laferriere
2007-01-16  4:16                       ` dean gaudet
2007-01-16  5:06                   ` Bill Davidsen

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=45AB9DC6.50509@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=robin-lists@robinbowes.com \
    /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.