public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: swidth in RAID
Date: Sun, 30 Jun 2013 21:47:36 -0500	[thread overview]
Message-ID: <51D0EDC8.2090706@hardwarefreak.com> (raw)
In-Reply-To: <20130701020939.GF27780@dastard>

On 6/30/2013 9:09 PM, Dave Chinner wrote:
> On Sun, Jun 30, 2013 at 06:54:31PM -0700, aurfalien wrote:
>>
>> On Jun 30, 2013, at 6:38 PM, Dave Chinner wrote:
>>
>>> On Sun, Jun 30, 2013 at 04:42:06PM -0500, Stan Hoeppner wrote:
>>>> On 6/30/2013 1:43 PM, aurfalien wrote:
>>>>
>>>>> I understand swidth should = #data disks.
>>>>
>>>> No.  "swidth" is a byte value specifying the number of 512 byte blocks
>>>> in the data stripe.
>>>>
>>>> "sw" is #data disks.
>>>>
>>>>> And the docs say for RAID 6 of 8 disks, that means 6.
>>>>>
>>>>> But parity is distributed and you actually have 8 disks/spindles working for you and a bit of parity on each.
>>>>>
>>>>> So shouldn't swidth equal disks in raid when its concerning distributed parity raid?
>>>>
>>>> No.  Lets try visual aids.
>>>>
>>>> Set 8 coffee cups (disk drives) on a table.  Grab a bag of m&m's.
>>>> Separate 24 blues (data) and 8 reds (parity).
>>>>
>>>> Drop a blue m&m in cups 1-6 and a red into 7-8.  You just wrote one RAID
>>>> stripe.  Now drop a blue into cups 3-8 and a red in 1-2.  Your second
>>>> write, this time rotating two cups (drives) to the right.  Now drop
>>>> blues into 5-2 and reds into 3-4.  You've written your third stripe,
>>>> rotating by two cups (disks) again.
>>>>
>>>> This is pretty much how RAID6 works.  Each time we wrote we dropped 8
>>>> m&m's into 8 cups, 6 blue (data chunks) and 2 red (parity chunks).
>>>> Every RAID stripe you write will be constructed of 6 blues and 2 reds.
>>>
>>> Right, that's how they are constructed, but not all RAID distributes
>>> parity across different disks in the array. Some are symmetric, some
>>> are asymmetric, some rotate right, some rotate left, and some use
>>> statistical algorithms to give an overall distribution without being
>>> able to predict where a specific parity block might lie within a
>>> stripe...
>>>
>>> And at the other end of the scale, isochronous RAID arrays tend to
>>> have dedicated parity disks so that data read and write behaviour is
>>> deterministic and therefore predictable from a high level....
>>>
>>> So, assuming that a RAID5/6 device has a specific data layout (be it
>>> distributed or fixed) at the filesystem level is just a bad idea. We
>>> simply don't know. Even if we did, the only thing we can optimise is
>>> the thing that is common between all RAID5/6 devices - writing full
>>> stripe widths is the most optimal method of writing to them....
>>
>> Am I interpreting this to say;
>>
>> 16 disks is sw=16 regardless of parity?
> 
> No. I'm just saying that parity layout is irrelevant to the
> filesystem and that all we care about is sw does not include parity
> disks.

So, here's the formula aurfalien, where #disks is the total number of
active disks (excluding spares) in the RAID array.  In the case of

RAID5	sw = (#disks - 1)
RAID6	sw = (#disks - 2)
RAID10  sw = (#disks / 2) [1]

[1] If using the Linux md/RAID10 driver with one of the non-standard
layouts such as n2 or f2, the formula may change.  This is beyond the
scope of this discussion.  Visit the linux-raid mailing list for further
details.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-07-01  2:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-30 18:43 swidth in RAID aurfalien
2013-06-30 19:08 ` Peter Grandi
2013-06-30 21:42 ` Stan Hoeppner
2013-06-30 22:36   ` aurfalien
2013-07-01  1:38   ` Dave Chinner
2013-07-01  1:54     ` aurfalien
2013-07-01  2:09       ` Dave Chinner
2013-07-01  2:47         ` Stan Hoeppner [this message]
2013-07-01  2:54           ` aurfalien
2013-07-02 21:48             ` Peter Grandi
2013-07-03  0:15               ` 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=51D0EDC8.2090706@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=xfs@oss.sgi.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