From: keld@keldix.com
To: Gionatan Danti <g.danti@assyoma.it>
Cc: Peter Grandi <pg@lxra2.for.sabi.co.UK>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: RAID 10 far and offset on-disk layouts
Date: Fri, 27 Dec 2013 19:26:24 +0100 [thread overview]
Message-ID: <20131227182624.GA14158@www5.open-std.org> (raw)
In-Reply-To: <52BDB9C0.2020906@assyoma.it>
On Fri, Dec 27, 2013 at 06:32:48PM +0100, Gionatan Danti wrote:
> ><snip>
> >Therefore the *probability* of loss of data because of 2 member
> >devices failing is higher in layout 1) than layout 2), whether
> >or not the drives are "adjacent".
> >
> > Note that arguably layout 1) is not really RAID10, because an
> > important property of RAID10 is or should be that there are
> > only N/2 pairs out of N drives. Otherwise it is not quite
> > 'RAID1' if a chunk position in a stripe can be replicated on 2
> > other devices, half the replicas on one and half on another.
> >
> >That the member devices are *adjacent* is irrelevant; what
> >matters is the statistical chance, which is driven by the
> >percent of cases where 2 failures result in data loss, which
> >driven by the number of paired drives.
>
> Very detailed answer, thank you Peter :)
>
> Based on what keld told before, the current scheme if n.2 (wikipedia's
> one), right? It is possible, using mdadm, understand the physical layout
> (if n.1 or n.2) of a live RAID10 array?
>
> As schema n.1 lead to increased probability of data loss, why offset
> layout use it instead of, say, some variance of schema n.2?
I am not sure of the probabilities on chances of surviving more
than 1 failing drive for the offset layout, but my intuition tells
me it is rather bad. As it shifts the blocks one block at a time,
my guts feeling is that it really cannot survive more than one
failing disk.
On the other hand raid10,far in the second layout (wikipedia - and
I am the author of the text:-) I am quite sure that the layout is
theoretically optimal, as you in the luckiest case can survive
n/2 drives failing, where n is your number of drives, and it is
integer division... I did the design of this layout for maximum
redundancy.
The main reason for chosing raid10,far is that it is faster
for single reads, a speed of raid0, while for other operations it is
about the same. For degraded arrays raid10,far is probably worse
than the other raid10 types, while the IO scheduling algorithm
probably remedies some of the bad raw performance on the degraded
raid10,far.
Also the use of inner and faster sectors of a hard drive gives
raid10,far an edge towards the other raid10 types.
Best regards
Keld
next prev parent reply other threads:[~2013-12-27 18:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-27 14:29 RAID 10 far and offset on-disk layouts Gionatan Danti
2013-12-27 14:46 ` Peter Grandi
2013-12-27 15:16 ` Gionatan Danti
2013-12-27 17:16 ` Peter Grandi
2013-12-27 17:32 ` Gionatan Danti
2013-12-27 18:26 ` keld [this message]
2013-12-27 15:19 ` keld
2013-12-27 15:22 ` Gionatan Danti
2013-12-27 15:49 ` keld
2014-01-09 8:03 ` Gionatan Danti
2014-01-12 23:20 ` NeilBrown
2014-01-13 8:52 ` Gionatan Danti
2014-01-13 9:45 ` NeilBrown
2014-01-13 10:15 ` Gionatan Danti
2014-01-13 22:27 ` NeilBrown
2014-01-13 23:38 ` keld
2014-01-14 0:46 ` Stan Hoeppner
2014-01-14 9:38 ` keld
2014-01-14 9:06 ` Gionatan Danti
2014-01-14 9:16 ` NeilBrown
2014-01-14 9:27 ` Gionatan Danti
2014-01-14 10:06 ` keld
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=20131227182624.GA14158@www5.open-std.org \
--to=keld@keldix.com \
--cc=g.danti@assyoma.it \
--cc=linux-raid@vger.kernel.org \
--cc=pg@lxra2.for.sabi.co.UK \
/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;
as well as URLs for NNTP newsgroup(s).