public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bryan J. Smith" <b.j.smith@ieee.org>
To: Justin Piszcz <jpiszcz@lucidpixels.com>,
	"Bryan J. Smith" <b.j.smith@ieee.org>
Cc: Ralf Gross <Ralf-Lists@ralfgross.de>, linux-xfs@oss.sgi.com
Subject: Re: [UNSURE] Re: mkfs options for a 16x hw raid5 and xfs (mostly large files)
Date: Wed, 26 Sep 2007 10:49:31 -0700 (PDT)	[thread overview]
Message-ID: <730488.2449.qm@web32905.mail.mud.yahoo.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0709261336080.24646@p34.internal.lan>

Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> Do you have any type of benchmarks to similate the load you are 
> mentioning?

Yes, write different, non-zero, 100GB data files from 30 NFSv3 sync
clients at the same time.  You can easily script firing that off and
get the number of seconds it takes to commit.

Use NFS with UDP to avoid the overhead of TCP.

> What did HW RAID drop to when the same test was run with SW 
> RAID / 50 MBps under load?

I saw an aggregate commit average of around 150MBps using a pair of
8-channel 3Ware Escalade 9550SX cards (each on their own PCI-X bus),
with a LVM stripe between them.  Understand the test literally took 5
hours to run!

The software RAID-50, two "dumb" SATA 8-channel Marvell cards (each
on their own PCI-X bus), with a LVM stripe between them, was not
completed after 15 hours (overnight).  So I finally terminated it.

Each system had a 4x GbE trunk to a layer-3 switch.  I would have run
the same test with SMB TCP/IP, possibly with a LeWiz 4x GbE RX TOE
HBA, except I honestly didn't have the time to wait on it.

> Did it achieve better performance due to an on-board /
> raid-card controller cache, or?

Has nothing to do with cache.  The OS is far better at scheduling and
buffering in the system RAM, in addition to the fact that it does an
async buffer, whereas many HW RAID drivers are sync to the NVRAM of
the HW RAID card (that's part of the problem with comparisons).

It has to do with the fact in software RAID-5 you are streaming 100%
of the data through the general system interconnect for the
LOAD-XOR-STO operation.  XORs are extrmely fast.  LOAD/STO through a
general purpose CPU is not.

It's the same reason why we don't use general purpose CPUs for
layer-3 switches either, but a "core" CPU with NPE (network processor
engine) ASICs.  Same deal with most HW RAID cards, a "core" CPU with
SPE ASICs -- for off-load from the general CPU system interconnect.

XORs are done "in-line" with the transfer, instead of hogging up the
system interconnect.  It's the direct difference between PIO and DMA.
 An in-line NPE/SPE ASIC basically acts like a DMA transfer,
real-time.  A general purpose CPU and its interconnect cannot do
that, so it has all the issues of PIO.

PIO in a general purpose CPU is to be avoided at all costs when you
have other needs for the system interconnect, like I/O.  If you don't
have much else bothering the I/O, like in a web server or read-only
system (where you're not doing the writes), then it doesn't matter,
and software RAID-5 is great.


-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith@ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
     Fission Power:  An Inconvenient Solution

  parent reply	other threads:[~2007-09-26 17:49 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-23  9:38 mkfs options for a 16x hw raid5 and xfs (mostly large files) Ralf Gross
2007-09-23 12:56 ` Peter Grandi
2007-09-26 14:54   ` Ralf Gross
2007-09-26 16:27     ` [UNSURE] " Justin Piszcz
2007-09-26 16:54       ` Ralf Gross
2007-09-26 16:59         ` Justin Piszcz
2007-09-26 17:38           ` Bryan J. Smith
2007-09-26 17:41             ` Justin Piszcz
2007-09-26 17:55               ` Bryan J. Smith
2007-09-26 17:13         ` [UNSURE] " Bryan J. Smith
2007-09-26 17:27           ` Justin Piszcz
2007-09-26 17:35             ` Bryan J. Smith
2007-09-26 17:37               ` Justin Piszcz
2007-09-26 17:38                 ` Justin Piszcz
2007-09-26 17:49                 ` Bryan J. Smith [this message]
2007-09-27 15:22     ` Ralf Gross
2007-09-24 17:31 ` Ralf Gross
2007-09-24 18:01   ` Justin Piszcz
2007-09-24 20:39     ` Ralf Gross
2007-09-24 20:43       ` Justin Piszcz
2007-09-24 21:33         ` Ralf Gross
2007-09-24 21:36           ` Justin Piszcz
2007-09-24 21:52             ` Ralf Gross
2007-09-25 12:35               ` Ralf Gross
2007-09-25 12:50                 ` Justin Piszcz
2007-09-25 13:44                   ` Bryan J Smith
2007-09-25 12:57                 ` KELEMEN Peter
2007-09-25 13:49                   ` Ralf Gross
2007-09-25 14:08                     ` Bryan J Smith
2007-09-25 16:07                       ` Ralf Gross
2007-09-25 16:28                         ` Bryan J. Smith
2007-09-25 17:25                           ` Ralf Gross
2007-09-25 17:41                             ` Bryan J. Smith
2007-09-25 19:13                               ` Ralf Gross
2007-09-25 20:23                                 ` Bryan J. Smith
2007-09-25 16:48                         ` Justin Piszcz
2007-09-25 18:00                           ` Bryan J. Smith
2007-09-25 18:33                             ` Ralf Gross
2007-09-25 23:38                             ` Justin Piszcz
2007-09-26  8:23                               ` Ralf Gross
2007-09-26  8:42                                 ` Justin Piszcz
2007-09-26  8:49                                   ` Ralf Gross
2007-09-26  9:52                                     ` Justin Piszcz
2007-09-26 15:03                                       ` Bryan J Smith
2007-09-26 15:15                                         ` Ralf Gross
2007-09-26 17:08                                           ` Bryan J. Smith
2007-09-26 16:24                                         ` Justin Piszcz
2007-09-26 17:11                                           ` Bryan J. Smith

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=730488.2449.qm@web32905.mail.mud.yahoo.com \
    --to=b.j.smith@ieee.org \
    --cc=Ralf-Lists@ralfgross.de \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox