All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: 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 18:32:48 +0100	[thread overview]
Message-ID: <52BDB9C0.2020906@assyoma.it> (raw)
In-Reply-To: <21181.46549.590241.76206@tree.ty.sabi.co.uk>

> <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?

Regards.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2013-12-27 17:32 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 [this message]
2013-12-27 18:26       ` keld
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=52BDB9C0.2020906@assyoma.it \
    --to=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 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.