From: keld@keldix.com
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: CoolCold <coolthecold@gmail.com>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: XFS on top RAID10 with odd drives count and 2 near copies
Date: Tue, 14 Feb 2012 12:38:32 +0100 [thread overview]
Message-ID: <20120214113832.GA6157@www5.open-std.org> (raw)
In-Reply-To: <4F39D9B2.3050305@hardwarefreak.com>
On Mon, Feb 13, 2012 at 09:49:06PM -0600, Stan Hoeppner wrote:
> On 2/13/2012 5:02 PM, keld@keldix.com wrote:
>
> > And anyway, I think a 7 spindle raid10,f2 would be much faster than
> > a md linear array setup, both for small files and for largish
> > sequential files. But try it out and report to us what you find.
>
> The results of the target workload should be interesting, given the
> apparent 7 spindles of stripe width of mdraid10,f2, and only 3 effective
> spindles with the linear array of mirror pairs, an apparent 4 spindle
> deficit.
>
> > I would expect a linear md, and also most other MD raids would tend to perform better in
> > the almost empty state, as the files will be placed on the faster parts of the spindles.
>
> This is not the case with XFS.
>
> > raid10,f2 would have a more uniform performance as it gets filled, because read access to
> > files would still be to the faster parts of the spindles.
>
> This may be the case with EXTx, Reiser, etc, but not with XFS.
>
> XFS creates its allocation groups uniformly across the storage device.
> So assuming your filesystem contains more than a handful of directories,
> even a very young XFS will have directories and files stored from outer
> to inner tracks.
Would not even XFS allocate lower AGs (on faster tracks) first?
> This layout of AGs, and the way XFS makes use of them, is directly
> responsible for much of XFS' high performance. For example, a single
> file create operation on a full EXTx filesystem will exhibit a ~30ms
> combined seek delay with an average 3.5" SATA disk. With XFS it will be
> ~10ms. This is because with EXTx the directories are at the outer edge
> and the free space is on the far inner edge. With XFS the directory and
> free space area few tracks apart within the same allocation group. Once
> you seek the directory in the AG, the seek latency from there to the
> track with the free space may be less than 1ms. The seek distance
> principal here is the same for single disks and RAID.
Well, I was talking for a given FS, including XFS. As raid10,f2 limits the read access to the
faster halves of the spindles, reads will never go to the slower halves.
On other raid types than raid10,far with regular use, AGs in use and data will be spread
randomly over the disks, including the slower inner tracks. Here raid10,far will only
use the outer tracks for reading, with some speed-up as a consequence.
best regards
keld
next prev parent reply other threads:[~2012-02-14 11:38 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 15:17 XFS on top RAID10 with odd drives count and 2 near copies CoolCold
2012-02-11 4:05 ` Stan Hoeppner
2012-02-11 14:32 ` David Brown
2012-02-12 20:16 ` CoolCold
2012-02-13 8:50 ` David Brown
2012-02-13 9:46 ` CoolCold
2012-02-13 11:19 ` David Brown
2012-02-13 13:46 ` Stan Hoeppner
2012-02-13 8:54 ` David Brown
2012-02-13 9:49 ` CoolCold
2012-02-13 12:09 ` Stan Hoeppner
2012-02-13 12:42 ` David Brown
2012-02-13 14:46 ` Stan Hoeppner
2012-02-13 21:40 ` CoolCold
2012-02-13 23:02 ` keld
2012-02-14 3:49 ` Stan Hoeppner
2012-02-14 8:58 ` David Brown
2012-02-14 11:38 ` keld [this message]
2012-02-14 23:27 ` Stan Hoeppner
2012-02-15 8:30 ` Robin Hill
2012-02-15 13:30 ` Stan Hoeppner
2012-02-15 14:03 ` Robin Hill
2012-02-15 15:40 ` David Brown
2012-02-17 13:16 ` Stan Hoeppner
2012-02-17 14:57 ` David Brown
2012-02-17 19:30 ` Peter Grandi
2012-02-18 13:59 ` David Brown
2012-02-19 14:46 ` Peter Grandi
2012-02-17 19:03 ` Peter Grandi
2012-02-17 22:12 ` Stan Hoeppner
2012-02-18 17:09 ` Peter Grandi
2012-02-15 9:24 ` keld
2012-02-15 12:10 ` David Brown
2012-02-15 13:08 ` keld
2012-02-17 18:44 ` Peter Grandi
2012-02-18 17:39 ` Peter Grandi
2012-02-14 7:31 ` CoolCold
2012-02-14 9:05 ` David Brown
2012-02-14 11:10 ` Stan Hoeppner
2012-02-14 2:49 ` 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=20120214113832.GA6157@www5.open-std.org \
--to=keld@keldix.com \
--cc=coolthecold@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=stan@hardwarefreak.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).