From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: XFS/Linux Sanity check
Date: Tue, 03 May 2011 20:10:17 -0500 [thread overview]
Message-ID: <4DC0A779.9030509@hardwarefreak.com> (raw)
In-Reply-To: <BANLkTik4YjSr7-VA+f9Sh+UxvKfFKMy=+w@mail.gmail.com>
On 5/2/2011 10:47 AM, Paul Anderson wrote:
Hi Paul,
> md apparently does not support barriers, so we are badly exposed in
> that manner, I know. As a test, I disabled write cache on all drives,
> performance dropped by 30% or so, but since md is apparently the
> problem, barriers still didn't work.
...
> Ideally, I'd firstly be able to find informed opinions about how I can
> improve this arrangement - we are mildly flexible on RAID controllers,
I'm not familiar enough with the md driver to address the barrier issue.
Try the mdadm mailing list. However...
You should be able to solve the barrier issue, and get additional
advantages, by simply swapping out the LSI 9200-8E's with the 9285-8E
w/cache battery. The 9285 has a dual core 800MHz PowerPC (vs single
core 533MHz on the 9280) and 1GB of cache. Configure 3x15 drive
hardware RAID6 arrays per controller, then stitch the resulting 9 arrays
together with mdraid or LVM striping or concatenation. I'd test both
under your normal multistreaming workload to see which works best.
A multilevel stripe will show better performance with an artificial
single stream test such as dd, but under your operational multiple
stream workload, concatenation may have similar performance, while at
the same time giving you additional capability, especially if done with
LVM instead of mdraid --linear. Using LVM concatenation enables
snapshots and the ability to grow and shrink the volume, neither of
which you can do with striping (RAID 0).
The 9285-8E will be pricier than the 9280-8E but it's well worth the
extra dollars, given the low overall cost percentage of the HBAs vs
total system cost. You'll get better performance and the data safety
you're looking for. Just make sure that in addition to BBWC on the HBAs
you have good UPS units backing the servers and SC847 chassis.
> very flexible on versions of Linux, etc, and can try other OS's as a
> last resort (but the leading contender here would be "something"
> running ZFS, and though I love ZFS, it really didn't seem to work well
> for our needs).
Supermicro product is usually pretty decent. However, "DIY" arrays
comprised of an inexpensive teir 2/3 vendor drive box/backplane/expander
and off the shelf drives, whose firmware may not all match, can often be
a recipe for problems that are difficult to troubleshoot. Your problems
may not be caused by a kernel issue at all. The kernel may simply be
showing the symptoms but not the cause.
You've ordered, if my math is correct, 675 'enterprise class' 2TB SATA
drives, 45 per chassis, 135 per system, 5 systems. Did you
specify/verify with the vendor that all drives must be of the same
manufacturing lot and have matching firmware? When building huge
storage subsystems it is critical that all drives behave the same, which
usually means identical firmware.
> Secondly, I welcome suggestions about which version of the linux
> kernel you'd prefer to hear bug reports about, as well as what kinds
> of output is most useful (we're getting all chassis set up with serial
> console so we can do kgdb and also full kernel panic output results).
Others are better qualified to answer this. I'm just the lowly hardware
guy on the list. ;)
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2011-05-04 1:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-02 15:47 XFS/Linux Sanity check Paul Anderson
2011-05-02 17:09 ` Andi Kleen
2011-05-02 17:13 ` Emmanuel Florac
2011-06-11 1:33 ` FYI: LSI rebuilding; and XFS speed V. raw - hints on maxing out 'dd'....(if not already obvious) Linda Walsh
2011-06-11 9:30 ` Emmanuel Florac
2011-06-11 16:48 ` Linda Walsh
2011-05-03 3:18 ` XFS/Linux Sanity check Dave Chinner
2011-05-03 8:58 ` Michael Monnerie
2011-05-03 16:05 ` Paul Anderson
2011-05-04 10:36 ` Stan Hoeppner
2011-05-04 6:18 ` Stan Hoeppner
2011-05-04 1:10 ` Stan Hoeppner [this message]
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=4DC0A779.9030509@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