From: Phillip Susi <psusi@ubuntu.com>
To: ashford@whisperpc.com, Chris Murphy <lists@colorremedies.com>
Cc: "sys.syphus" <syssyphus@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: I need to P. are we almost there yet?
Date: Tue, 30 Dec 2014 16:44:14 -0500 [thread overview]
Message-ID: <54A31CAE.4020606@ubuntu.com> (raw)
In-Reply-To: <7e0d08fddb1e0060f756690f6c82c350.squirrel@webmail.wanet.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/29/2014 7:20 PM, ashford@whisperpc.com wrote:
> Just some background data on traditional RAID, and the chances of
> survival with a 2-drive failure.
>
> In traditional RAID-10, the chances of surviving a 2-drive failure
> is 66% on a 4-drive array, and approaches 100% as the number of
> drives in the array increase.
>
> In traditional RAID-0+1 (used to be common in low-end fake-RAID
> cards), the chances of surviving a 2-drive failure is 33% on a
> 4-drive array, and approaches 50% as the number of drives in the
> array increase.
In terms of data layout, there is really no difference between raid-10
( or raid1+0 ) and raid0+1, aside from the designation you assign to
each drive. With a dumb implementation of 0+1, any single drive
failure offlines the entire stripe, discarding the remaining good
disks in it, thus giving the probability you describe as the only
possible remaining failure(s) that do not result in the mirror also
failing is a drive in the same stripe as the original. This however,
is only a deficiency of the implementation, not the data layout, as
all of the data on the first failed drive could be recovered from a
drive in the second stripe, so long as the second drive that failed
was any drive other than the one holding the duplicate data of the first.
This is partly why I agree with linux mdadm that raid10 is *not*
simply raid1+0; the latter is just a naive, degenerate implementation
of the former.
> In traditional RAID-1E, the chances of surviving a 2-drive failure
> is 66% on a 4-drive array, and approaches 100% as the number of
> drives in the array increase. This is the same as for RAID-10.
> RAID-1E allows an odd number of disks to be actively used in the
> array.
What some vendors have called "1E" is simply raid10 in the default
"near" layout to mdadm. I prefer the higher performance "offset"
layout myself.
> I'm wondering which of the above the BTRFS implementation most
> closely resembles.
Unfortunately, btrfs just uses the naive raid1+0, so no 2 or 3 disk
raid10 arrays, and no higher performing offset layout.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJUoxyuAAoJENRVrw2cjl5R72oH/1nypXV72Bk4PBeaGAwH7559
lL6JH80216lbhv8hHopIeXKe7uqPGFAE5F1ArChIi08HA+CqKr5cfPNzJPlobyFj
KNLzeXi+wnJO2mbvWnnJak83GVmvpBnYvS+22RCweDELCb3pulybleJnN4yVSL25
WpVfUGnAg5lQJdX2l6THeClWX6V47NKqD6iXbt9+jyADCK2yk/5+TVbS8tixFUtj
PBxe+XGNrkTREnPAAFy6BgwO2vCD92F6+mm/lHJ0fg7gOm41UE09gzabsCGQ9LFA
kk99c9WAnJdkTqUJVw49MEwmmhs/2gluKWTeaHONpBePoFIpQEjHI89TqBsKhY4=
=+oed
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-12-30 21:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-29 18:56 I need to P. are we almost there yet? sys.syphus
2014-12-29 19:00 ` sys.syphus
2014-12-29 19:04 ` Hugo Mills
2014-12-29 20:25 ` sys.syphus
2014-12-29 21:50 ` Hugo Mills
2014-12-29 21:16 ` Chris Murphy
2014-12-30 0:20 ` ashford
[not found] ` <CALBWd85UsSih24RhwpmDeMjuMWCKj9dGeuZes5POj6qEFkiz2w@mail.gmail.com>
2014-12-30 17:09 ` Fwd: " Jose Manuel Perez Bethencourt
2014-12-30 21:44 ` Phillip Susi [this message]
2014-12-30 23:17 ` ashford
2014-12-31 2:45 ` Phillip Susi
2014-12-31 17:27 ` ashford
2014-12-31 23:38 ` Phillip Susi
2015-01-01 1:26 ` Chris Samuel
2015-01-01 20:12 ` Roger Binns
2015-01-02 3:47 ` Duncan
2015-01-02 13:42 ` Austin S Hemmelgarn
2015-01-02 17:45 ` Brendan Hide
2015-01-02 19:41 ` Austin S Hemmelgarn
2014-12-29 21:13 ` Chris Murphy
2015-01-03 11:34 ` Bob Marley
2015-01-03 13:11 ` Duncan
2015-01-03 18:53 ` Bob Marley
2015-01-03 19:03 ` sys.syphus
2015-01-03 18:55 ` sys.syphus
2015-01-04 3:22 ` Duncan
2015-01-04 3:54 ` Hugo Mills
2015-01-03 21:58 ` Roman Mamedov
2015-01-04 3:24 ` Duncan
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=54A31CAE.4020606@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=ashford@whisperpc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=syssyphus@gmail.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;
as well as URLs for NNTP newsgroup(s).