All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keld Simonsen <keld@keldix.com>
To: Simon Matthews <simon.d.matthews@gmail.com>
Cc: "Tomáš Dulík" <dulik@unart.cz>,
	st0ff@npl.de, "Linux RAID" <linux-raid@vger.kernel.org>
Subject: Re: raid10,f2 Add a Controller: Which drives to move?
Date: Tue, 13 Apr 2010 11:23:54 +0200	[thread overview]
Message-ID: <20100413092354.GA7581@rap.rap.dk> (raw)
In-Reply-To: <j2t40b437201004122026zd43aa129nb501cfc83d5cdafd@mail.gmail.com>

I am not sure it has been said, but for a 4 disk raid10,f2 array
you should place the first and the second disk on one controller, and then the 3rd
and 4th on the second controller. Then you would have a copy of all blocks even
if one controller fails.

I believe the order is defined by the order the disks are specified in
on the mdadm --create line.

best regards
keld

On Mon, Apr 12, 2010 at 08:26:55PM -0700, Simon Matthews wrote:
> 2010/4/12 Tomáš Dulík <dulik@unart.cz>:
> > Stefan /*St0fF*/ Hübner napsal(a):
> >>
> >> I cannot quite understand your problem.  As every part of the array
> >> contains it's own metadata, it doesn't matter to md which /dev/sdX a
> >> drive is.  It might matter a bit for boot-time assembly, but actually
> >> that's what UUIDs are for.
> >>
> >
> > I know how UUIDs work.
> > My problem with device names is not a "critical", it's about "user
> > friendliness" of the physical disk management.
> > If a disk fails and I receive email "A Fail event had been detected on md
> > device /dev/md2. It could be related to component device /dev/sdd3", how
> > will I know which disk should be replaced, if the device name is not
> > fixed/persistent? I
> 
> Record the serial number of the disks and  which bay they are in.
> --
> 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
--
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

  reply	other threads:[~2010-04-13  9:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11 17:08 raid10,f2 Add a Controller: Which drives to move? Michael McCallister
2010-04-11 21:31 ` Michael Evans
2010-04-12  6:17   ` Michael McCallister
2010-04-12  3:41 ` Tomáš Dulík
2010-04-12  6:07   ` Stefan /*St0fF*/ Hübner
2010-04-12  7:43     ` Tomáš Dulík
2010-04-13  3:26       ` Simon Matthews
2010-04-13  9:23         ` Keld Simonsen [this message]
2010-04-13 13:09           ` Neil Brown
2010-04-12  6:07   ` Michael McCallister

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=20100413092354.GA7581@rap.rap.dk \
    --to=keld@keldix.com \
    --cc=dulik@unart.cz \
    --cc=linux-raid@vger.kernel.org \
    --cc=simon.d.matthews@gmail.com \
    --cc=st0ff@npl.de \
    /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.