From: Stan Hoeppner <stan@hardwarefreak.com>
To: "C. Morgan Hamill" <chamill@wesleyan.edu>, xfs <xfs@oss.sgi.com>
Subject: Re: Question regarding XFS on LVM over hardware RAID.
Date: Wed, 29 Jan 2014 17:55:48 -0600 [thread overview]
Message-ID: <52E99504.4030902@hardwarefreak.com> (raw)
In-Reply-To: <1391022066-sup-5863@al.wesleyan.edu>
On 1/29/2014 1:11 PM, C. Morgan Hamill wrote:
> Thanks for the quick reply.
>
> Excerpts from Eric Sandeen's message of 2014-01-29 10:07:15 -0500:
>> The stripe unit and width are units of geometry of the underlying
>> storage; a filesystem will span some number of stripe units, depending
>> on its size.
>>
>> So no, the filesystem's notion of stripe geometry does not change
>> with the filesystem size.
>>
>> You do want to make sure that stripe geometry is correct and aligned
>> from top to bottom.
>
> Just to make sure I've understood, for 3 14-disk RAID 6 groups striped
> together into a single RAID 60, with stripe units of 128k, split up into
> some number of LVM logical volumes, I'd create the filesystems with the
> following:
>
> mkfs.xfs -d su=128k,sw=36 ...
This is not correct. You must align to either the outer stripe or the
inner stripe when using a nested array. In this case it appears your
inner stripe is RAID6 su 128KB * sw 12 = 1536KB. You did not state your
outer RAID0 stripe geometry. Which one you align to depends entirely on
your workload.
However, given that you currently intend to assemble one large array
from 3 smaller arrays, then immediately carve it into smaller pieces,
it's seems that RAID60 is probably not the correct architecture for your
workload. RAID60 is suitable for very large streaming write/read
workloads where you are evenly distributing filesystem blocks across a
very large spindle count, with a deterministic IO pattern, and with no
RMW. It is not very suitable for consolidation workloads, as you seem
to be describing here.
Everything starts and ends with the workload. You always design the
storage to meet the needs of the workload, not the other way round. You
seem to be designing your system from the storage up. This is often a
recipe for disaster.
Please describe your workload in more detail so we can provide better,
detailed, advice.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-01-29 23:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 14:26 Question regarding XFS on LVM over hardware RAID C. Morgan Hamill
2014-01-29 15:07 ` Eric Sandeen
2014-01-29 19:11 ` C. Morgan Hamill
2014-01-29 23:55 ` Stan Hoeppner [this message]
2014-01-30 14:28 ` C. Morgan Hamill
2014-01-30 20:28 ` Dave Chinner
2014-01-31 5:58 ` Stan Hoeppner
2014-01-31 21:14 ` C. Morgan Hamill
2014-02-01 21:06 ` Stan Hoeppner
2014-02-02 21:21 ` Dave Chinner
2014-02-03 16:12 ` C. Morgan Hamill
2014-02-03 21:41 ` Dave Chinner
2014-02-04 8:00 ` Stan Hoeppner
2014-02-18 19:44 ` C. Morgan Hamill
2014-02-18 23:07 ` Stan Hoeppner
2014-02-20 18:31 ` C. Morgan Hamill
2014-02-21 3:33 ` Stan Hoeppner
2014-02-21 8:57 ` Emmanuel Florac
2014-02-22 2:21 ` Stan Hoeppner
2014-02-25 17:04 ` C. Morgan Hamill
2014-02-25 17:17 ` Emmanuel Florac
2014-02-25 20:08 ` Stan Hoeppner
2014-02-26 14:19 ` C. Morgan Hamill
2014-02-26 17:49 ` Stan Hoeppner
2014-02-21 19:17 ` C. Morgan Hamill
2014-02-03 16:07 ` C. Morgan Hamill
2014-01-29 22:40 ` Stan Hoeppner
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=52E99504.4030902@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=chamill@wesleyan.edu \
--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;
as well as URLs for NNTP newsgroup(s).