From: NeilBrown <neilb@suse.de>
To: Jonathan Tripathy <jonnyt@abpni.co.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: Which Disks can fail?
Date: Tue, 21 Jun 2011 21:42:25 +1000 [thread overview]
Message-ID: <20110621214225.5f65ece0@notabene.brown> (raw)
In-Reply-To: <4E0078E9.7070208@abpni.co.uk>
On Tue, 21 Jun 2011 11:56:41 +0100 Jonathan Tripathy <jonnyt@abpni.co.uk>
wrote:
>
> On 21/06/2011 11:45, NeilBrown wrote:
> > On Tue, 21 Jun 2011 11:24:20 +0100 Jonathan Tripathy<jonnyt@abpni.co.uk>
> > wrote:
> >
> >> Hi Everyone,
> >>
> >> Use md's "single process" RAID10 with the standard near layout (which is
> >> apperently the same as RAID1+0 in industry), which 2 drives could fail
> >> without loosing the array?
> >>
> >> This is what I have:
> >>
> >> Number Major Minor RaidDevice State
> >> 0 8 5 0 active sync /dev/sda5
> >> 1 8 21 1 active sync /dev/sdb5
> >> 2 8 37 2 active sync /dev/sdc5
> >> 3 8 53 3 active sync /dev/sdd5
> >>
> >> Thanks
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Run
> >
> > man 4 md
> >
> > search for "RAID10"
> >
> > read what you find, and if it doesn't make sense, ask again.
> > If it does make sense, post your answer and feel free to ask for
> > confirmation.
> >
> >
> > NeilBrown
> Sorry, it still doesn't make much sense to me I'm afraid.
>
> In fact, it's confused me more - since I'm using "near", does that means
> that the "copy" (I'm using near=2) of a given trunk may lie on the same
> disk, leading to *no redundancy*??
Clearly I need to improve the man page... (suggestions welcome).
How do you read it that the copies of a given chunk may lie on the same disk.
I read:
When 'near' replicas are chosen, the multiple copies of a given chunk
are laid out consecutively across the stripes of the array, so the two
copies of a datablock will likely be at the same offset on two adjacent
devices.
"laid out consecutively across the stripes of the array" might be a bit
obscure.. A stripe is one chunk on each device, so when chunks a laid out
consecutively across a stripe, they would be one chunk per device.
Then "likely be at the same offset on two adjacent devices" should make this
clearer. It is only "likely" because if you have an odd number of devices,
then the 2 copies of one chunk could be
a/ at offset X on the last device
b/ at offset X+chunk on the first device
but in general, they are on "adjacent devices"
So in answer to your original question, sda5 and sdb5 will have the same
data, and sdc5 and sdd5 will also have the same data.
NeilBrown
next prev parent reply other threads:[~2011-06-21 11:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 10:24 Which Disks can fail? Jonathan Tripathy
2011-06-21 10:45 ` NeilBrown
2011-06-21 10:56 ` Jonathan Tripathy
2011-06-21 11:42 ` NeilBrown [this message]
2011-06-21 11:57 ` Jonathan Tripathy
2011-06-21 15:31 ` Jonathan Tripathy
2011-06-23 7:02 ` NeilBrown
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=20110621214225.5f65ece0@notabene.brown \
--to=neilb@suse.de \
--cc=jonnyt@abpni.co.uk \
--cc=linux-raid@vger.kernel.org \
/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).