All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Dusty Mabe <dustymabe@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: 0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation
Date: Fri, 10 May 2013 07:29:06 +1000	[thread overview]
Message-ID: <20130510072906.6d457c29@notabene.brown> (raw)
In-Reply-To: <CAFfJ-R6Fgz+Mye2FX5D-+uaM0jgUe2j4nnE1ACyCwwk=9X-KPQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Thu, 9 May 2013 11:30:26 -0400 Dusty Mabe <dustymabe@gmail.com> wrote:

> On Wed, May 8, 2013 at 1:39 PM, Dusty Mabe <dustymabe@gmail.com> wrote:
> > CentOS 6.3
> > 2.6.32-279.19.1
> > mdadm-3.2.3-9.el6.x86_64
> >
> >
> > I have noticed that the device number printed in the mdstat file gets
> > changed if you fail->remove->add a member device of a 1.X metadata
> > array, but for a 0.90 metadata array the device will go back to the
> > original value once recovery has finished.
> >
> >
> > Is this by design? I know 1.X version of metadata use dev_roles rather
> > than this_disk and the mdp_disk_t structure so maybe it is by design?
> >
> 
> Hey guys.. Sorry to be a pain. Has anyone seen this before? Is it by
> design or a known issue?
> 
It is an unfortunate consequence of incoherent design.
I've occasionally wondered if I should "fix" it.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-05-09 21:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08 17:39 0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation Dusty Mabe
2013-05-09 15:30 ` Dusty Mabe
2013-05-09 21:29   ` NeilBrown [this message]
2013-05-11  0:04     ` Dusty Mabe
2013-05-14 20:31       ` Dusty Mabe
2013-05-16  0:41       ` NeilBrown
2013-05-16  4:14         ` Dusty Mabe

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=20130510072906.6d457c29@notabene.brown \
    --to=neilb@suse.de \
    --cc=dustymabe@gmail.com \
    --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 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.