From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: swidth in RAID
Date: Mon, 1 Jul 2013 11:38:51 +1000 [thread overview]
Message-ID: <20130701013851.GC27780@dastard> (raw)
In-Reply-To: <51D0A62E.2020309@hardwarefreak.com>
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....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-01 1:38 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 [this message]
2013-07-01 1:54 ` aurfalien
2013-07-01 2:09 ` Dave Chinner
2013-07-01 2:47 ` Stan Hoeppner
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=20130701013851.GC27780@dastard \
--to=david@fromorbit.com \
--cc=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