From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: A little RAID experiment
Date: Mon, 16 Jul 2012 20:39:15 -0500 [thread overview]
Message-ID: <5004C243.6040404@hardwarefreak.com> (raw)
In-Reply-To: <CAAxjCEw-NJzZmX3Q5CJ+aZ_Q7Yo39pMU=-hiXk0ghTMq7q3PWA@mail.gmail.com>
On 7/16/2012 4:58 PM, Stefan Ring wrote:
> I'm pretty sure that the data is correct, and the test is not flawed.
That may be true. Nonetheless, what you presented does not paint a
coherent picture.
> The only relevant omission is that I've run the test a few times in a
> row.
You also omitted whether you had exclusive access to the P2000 array.
The P2000 has 2GB write cache. The numbers you report are far below
what this unit is capable of. Your data suggests
1. You didn't have exclusive access during testing
2. A configuration issue
>> Again, the response times suggest all these writes are being
>> acknowledged by BBWC. Given this is a PCIe RAID HBA, the throughput
>> numbers to BBWC should be hundreds of megs per second.
>
> It's semi-random, quite small writes -- actually not very random, but
> still not exactly linear --, so some performance degradation is
> expected.
The data set I commented on here shows all responses were from BBWC.
How can you "expect" degradation from cache?
>> Again, due to the response times, all the writes appear acknowledged by
>> BBWC. While the LSI throughput is better, it is still far far lower
>> than what it should be, i.e. hundreds of megs per second to BBWC.
>
> The cache gets filled up quickly in this case, so it can only accept
> as much data as it manages to write out to the disks.
This is not what the data I quoted shows Stefan. The data shows all the
writes were acked by cache, according to response times.
> Maybe so, but it might also be worthwhile to point out flaws with
> current real hardware, when it does not behave the way one would
> expect.
The only "flaw" you've identified, long ago, is that low end HP hardware
based RAID5/6 is not suitable for metadata heavy workloads. Everyone
here told you RAID5/6, whether hardware or software, was not a good
candidate for such workloads. You played with RAID10 and a concat
setup, and received greatly enhanced performance.
It depends on the one, and what the one expects. Most people on this
list would never expect parity RAID to perform well with the workloads
you're throwing at it. Your expectations are clearly different than
most on this list.
The kicker here is that most of the data you presented shows almost all
writes being acked by cache, in which case RAID level should be
irrelevant, but at the same time showing abysmal throughput. When all
write hit cache, throughput should be through the roof.
So again, something is amiss here.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-07-17 1:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 8:07 A little RAID experiment Stefan Ring
2012-04-25 14:17 ` Roger Willcocks
2012-04-25 16:23 ` Stefan Ring
2012-04-27 14:03 ` Stan Hoeppner
2012-04-26 8:53 ` Stefan Ring
2012-04-27 15:10 ` Stan Hoeppner
2012-04-27 15:28 ` Joe Landman
2012-04-28 4:42 ` Stan Hoeppner
2012-04-27 13:50 ` Stan Hoeppner
2012-05-01 10:46 ` Stefan Ring
2012-05-30 11:07 ` Stefan Ring
2012-05-31 1:30 ` Stan Hoeppner
2012-05-31 6:44 ` Stefan Ring
2012-07-16 19:57 ` Stefan Ring
2012-07-16 20:03 ` Stefan Ring
2012-07-16 20:05 ` Stefan Ring
2012-07-16 21:27 ` Stan Hoeppner
2012-07-16 21:58 ` Stefan Ring
2012-07-17 1:39 ` Stan Hoeppner [this message]
2012-07-17 5:26 ` Dave Chinner
2012-07-18 2:18 ` Stan Hoeppner
2012-07-18 6:44 ` Stefan Ring
2012-07-18 7:09 ` Stan Hoeppner
2012-07-18 7:22 ` Stefan Ring
2012-07-18 10:24 ` Stan Hoeppner
2012-07-18 12:32 ` Stefan Ring
2012-07-18 12:37 ` Stefan Ring
2012-07-19 3:08 ` Stan Hoeppner
2012-07-25 9:29 ` Stefan Ring
2012-07-25 10:00 ` Stan Hoeppner
2012-07-25 10:08 ` Stefan Ring
2012-07-25 11:00 ` Stan Hoeppner
2012-07-26 8:32 ` Dave Chinner
2012-09-11 16:37 ` Stefan Ring
2012-07-16 22:16 ` Stefan Ring
2012-10-10 14:57 ` Stefan Ring
2012-10-10 21:27 ` Dave Chinner
2012-10-10 22:01 ` Stefan Ring
-- strict thread matches above, loose matches on Subject: below --
2012-04-26 22:33 Richard Scobie
2012-04-27 21:30 ` Emmanuel Florac
2012-04-28 4:15 ` Richard Scobie
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=5004C243.6040404@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=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