From: Stan Hoeppner <stan@hardwarefreak.com>
To: keld@keldix.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 17:27:43 -0600 [thread overview]
Message-ID: <4F3AEDEF.2000608@hardwarefreak.com> (raw)
In-Reply-To: <20120214113832.GA6157@www5.open-std.org>
On 2/14/2012 5:38 AM, keld@keldix.com wrote:
> 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.
Maybe I simply don't understand this 'magic' of the f2 and far layouts.
If you only read the "faster half" of a spindle, does this mean writes
go to the slower half? If that's the case, how can you read data that's
never been written?
--
Stan
next prev parent reply other threads:[~2012-02-14 23:27 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
2012-02-14 23:27 ` Stan Hoeppner [this message]
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=4F3AEDEF.2000608@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=coolthecold@gmail.com \
--cc=keld@keldix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.