All of lore.kernel.org
 help / color / mirror / Atom feed
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.
>


  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.