Re: 0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation
From: NeilBrown <hidden>
Date: 2013-05-16 00:41:39
On Fri, 10 May 2013 20:04:27 -0400 Dusty Mabe [off-list ref] wrote:
quoted hunk ↗ jump to hunk
On Thu, May 9, 2013 at 5:29 PM, NeilBrown [off-list ref] wrote:quoted
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 Attachments
- signature.asc [application/pgp-signature] 828 bytes