From: Stan Hoeppner <stan@hardwarefreak.com>
To: David Brown <david@westcontrol.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: potentially lost largeish raid5 array..
Date: Sat, 24 Sep 2011 11:38:52 -0500 [thread overview]
Message-ID: <4E7E079C.4020802@hardwarefreak.com> (raw)
In-Reply-To: <j5ksf5$oam$1@dough.gmane.org>
On 9/24/2011 10:16 AM, David Brown wrote:
> On 24/09/2011 14:17, Stan Hoeppner wrote:
>> On 9/23/2011 7:11 PM, Thomas Fjellstrom wrote:
>>> On September 23, 2011, Stan Hoeppner wrote:
>>
>>>> When properly configured XFS will achieve near spindle throughput.
>>>> Recent versions of mkfs.xfs read the mdraid configuration and configure
>>>> the filesystem automatically for sw, swidth, number of allocation
>>>> groups, etc. Thus you should get max performance out of the gate.
>>>
>>> What happens when you add a drive and reshape? Is it enough just to
>>> tweak the
>>> mount options?
>>
>> When you change the number of effective spindles with a reshape, and
>> thus the stripe width and stripe size, you definitely should add the
>> appropriate XFS mount options and values to reflect this. Performance
>> will be less than optimal if you don't.
>>
>> If you use a linear concat under XFS you never have to worry about the
>> above situation. It has many other advantages over a striped array and
>> better performance for many workloads, especially multi user general
>> file serving and maildir storage--workloads with lots of concurrent IO.
>> If you 'need' maximum single stream performance for large files, a
>> striped array is obviously better. Most applications however don't need
>> large single stream performance.
>>
>
> If you use a linear concatenation of drives for XFS, is it not correct
> that you want one allocation group per drive (or per raid set, if you
> are concatenating a bunch of raid sets)?
Yes. Normally with a linear concat you would make X number of RAID1
mirrors via mdraid or hardware RAID, then concat them with mdadm
--linear or LVM. Then mkfs.xfs -d ag=X ...
Currently XFS has a 1TB limit for allocation groups. If you use 2TB
drives you'll get 2 AGs per effective spindle instead of one. With some
'borderline' workloads this may hinder performance. It depends on how
many top level directories you have in the filesystem and your
concurrency to them.
> If you then add another drive
> or raid set, can you grow XFS with another allocation group?
XFS creates more allocation groups automatically as part of the grow
operation. If you have a linear concat setup you'll obviously wan to
control this manually to maintain the same number of AGs per effective
spindle.
Always remember that the key to linear concat performance with XFS is
directory level parallelism. If you have lots of top level directories
in your filesystem and high concurrent access (home dirs, maildir, etc)
it will typically work better than a striped array. If you have few
directories and low concurrency, are streaming large files, etc, stick
with a striped array.
Also note that a linear concat will only give increased performance with
XFS, again for appropriate worklods. Using a linear concat with EXT3/4
will give you the performance of a single spindle regardless of the
total number of disks used. So one should stick with striped arrays for
EXT3/4.
--
Stan
next prev parent reply other threads:[~2011-09-24 16:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-23 1:50 potentially lost largeish raid5 array Thomas Fjellstrom
2011-09-23 4:32 ` NeilBrown
2011-09-23 4:49 ` Thomas Fjellstrom
2011-09-23 4:58 ` Roman Mamedov
2011-09-23 5:10 ` Thomas Fjellstrom
2011-09-23 7:06 ` David Brown
2011-09-23 7:37 ` Thomas Fjellstrom
2011-09-23 12:56 ` Stan Hoeppner
2011-09-23 13:28 ` David Brown
2011-09-23 16:22 ` Thomas Fjellstrom
2011-09-23 23:24 ` Stan Hoeppner
2011-09-24 0:11 ` Thomas Fjellstrom
2011-09-24 12:17 ` Stan Hoeppner
2011-09-24 13:11 ` (unknown) Tomáš Dulík
2011-09-24 15:16 ` potentially lost largeish raid5 array David Brown
2011-09-24 16:38 ` Stan Hoeppner [this message]
2011-09-25 13:03 ` David Brown
2011-09-25 14:39 ` Stan Hoeppner
2011-09-25 15:18 ` David Brown
2011-09-25 23:58 ` Stan Hoeppner
2011-09-26 10:51 ` David Brown
2011-09-26 19:52 ` Stan Hoeppner
2011-09-26 20:29 ` David Brown
2011-09-26 23:28 ` Krzysztof Adamski
2011-09-27 3:53 ` Stan Hoeppner
2011-09-24 17:48 ` Thomas Fjellstrom
2011-09-24 5:59 ` Mikael Abrahamsson
2011-09-24 17:53 ` Thomas Fjellstrom
2011-09-25 18:07 ` Robert L Mathews
2011-09-26 6:08 ` Mikael Abrahamsson
2011-09-26 2:26 ` Krzysztof Adamski
2011-09-23 5:11 ` NeilBrown
2011-09-23 5:22 ` Thomas Fjellstrom
2011-09-23 8:09 ` Thomas Fjellstrom
2011-09-23 9:15 ` NeilBrown
2011-09-23 16:26 ` Thomas Fjellstrom
2011-09-25 9:37 ` NeilBrown
2011-09-24 21:57 ` Aapo Laine
2011-09-25 9:18 ` Kristleifur Daðason
2011-09-25 10:10 ` NeilBrown
2011-10-01 23:21 ` Aapo Laine
2011-10-02 17:00 ` Aapo Laine
2011-10-05 2:13 ` NeilBrown
2011-10-05 2:06 ` NeilBrown
2011-11-05 12:17 ` Alexander Lyakas
2011-11-06 21:58 ` NeilBrown
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=4E7E079C.4020802@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=david@westcontrol.com \
--cc=linux-raid@vger.kernel.org \
/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).