From: David Brown <david@westcontrol.com>
To: stan@hardwarefreak.com
Cc: keld@keldix.com, 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: Wed, 15 Feb 2012 16:40:38 +0100 [thread overview]
Message-ID: <4F3BD1F6.8080309@westcontrol.com> (raw)
In-Reply-To: <4F3BB385.4000608@hardwarefreak.com>
On 15/02/2012 14:30, Stan Hoeppner wrote:
> On 2/15/2012 2:30 AM, Robin Hill wrote:
>> On Tue Feb 14, 2012 at 05:27:43PM -0600, Stan Hoeppner wrote:
>>
>>> 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?
>>>
>> Writes go to both halves, as normal for a mirrored setup, which is why
>
> Huh? A 'normal' RAID setup mirrors one disk to another. You're
> describing data being mirrored from the outer half of a single disk to
> the inner half. Where's the Redundancy in this? This doesn't make sense.
>
Like Robin said, and like I said in my earlier post, the second copy is
on a different disk.
>> its write performance is lower than that of a near layout array (more
>> head movement required). Reads will (normally) come from the faster
>> (outer) half of the disk though, so read performance is better. In most
>> cases workloads are read-heavy, so this comes out as a significant gain.
>
> Again, this makes no sense. You're simply repeating what David said.
> Neither of you seem to really understand this, or are simply unable to
> explain it correctly, technically.
>
As far as I can see, you are the only one in this thread who doesn't
understand this. I'm not sure where the problem lies, as several people
(including me) have given you explanations that seem pretty clear to me.
But maybe there is some fundamental point that we are assuming is
obvious, but you don't get - hopefully it will suddenly click in place
for you.
Have a look at this:
<http://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10>
Forget writes for a moment. Forget the second copy on the inner halves
of the disks. Then as far as reading is concerned, the raid10,f2 layout
looks /exactly/ like a raid0 stripe, using only the outer halves of the
disks. That means large reads use all the spindles as they read whole
stripes at a time, just like raid0. And because all data is on the
outer halves of the disks, the average bandwidth is higher than if it
were spread over the whole disk, and the average seek is faster because
the head movement is smaller - this is standard "short stroking" speed
improvement.
Write performance is lower because it needs more head movement to make
the second copy in the inner halves of the disks (as well as the copy to
the outer halves). But if you have a reasonable read-to-write ratio,
the total performance is higher overall.
> Maybe Neil will jump into the fray and answer my original question.
>
next prev parent reply other threads:[~2012-02-15 15:40 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
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 [this message]
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=4F3BD1F6.8080309@westcontrol.com \
--to=david@westcontrol.com \
--cc=coolthecold@gmail.com \
--cc=keld@keldix.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 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.