linux-raid.vger.kernel.org archive mirror
 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: Thu, 16 May 2013 10:41:39 +1000	[thread overview]
Message-ID: <20130516104139.1a904f3f@notabene.brown> (raw)
In-Reply-To: <CAFfJ-R5_Hcu37DNvQQw8tDyvJPktg8YAvgs-L+CyrVBB4ZRBcw@mail.gmail.com>

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

On Fri, 10 May 2013 20:04:27 -0400 Dusty Mabe <dustymabe@gmail.com> wrote:

> On Thu, May 9, 2013 at 5:29 PM, NeilBrown <neilb@suse.de> wrote:
> >
> > It is an unfortunate consequence of incoherent design.
> > I've occasionally wondered if I should "fix" it.
> 
> Neil,
> 
> Thanks for the insight. I don't know the code well but I do notice
> that changing the md_seq_show() function to print out the raid_disk
> rather than desc_nr at least gives me the "desired" behavior from
> /proc/mdstat. This still doesn't change the fact that the "Number" is
> still changed in the mdadm --detail output but is a quick easy way to
> change mdstat without actually having to re-architect anything.
> 
> What do you think?
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index aeceedf..b47fd35 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -7023,7 +7023,7 @@ static int md_seq_show(struct seq_file *seq, void *v)
>                 rdev_for_each(rdev, mddev) {
>                         char b[BDEVNAME_SIZE];
>                         seq_printf(seq, " %s[%d]",
> -                               bdevname(rdev->bdev,b), rdev->desc_nr);
> +                               bdevname(rdev->bdev,b), rdev->raid_disk);
>                         if (test_bit(WriteMostly, &rdev->flags))
>                                 seq_printf(seq, "(W)");
>                         if (test_bit(Faulty, &rdev->flags)) {

The problem with doing this is that it is potentially an API change.
It is unlikely but possible that some script depends on the current meaning
of the number.

Also it would result in spares being reported as e.g.
     sda1[-1]S
as 'raid_disk' for a spare is '-1'.


My leaning is to not worry too much about /proc/mdstat, but instead add a
"--status" option to "mdadm" which prints out a summary similar
to /proc/mdstat, but more coherent and less full of noise.

mdadm --status

md0 : raid1 chunk=65536K bitmap_chunk=8KB metadata=1.2 size=976762496K
   Working: 3[U_U] sda[0] sdc[1]
   Spares: sdd
   Failed: sdb

or something like that.

NeilBrown

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

  parent reply	other threads:[~2013-05-16  0:41 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
2013-05-11  0:04     ` Dusty Mabe
2013-05-14 20:31       ` Dusty Mabe
2013-05-16  0:41       ` NeilBrown [this message]
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=20130516104139.1a904f3f@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 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).