Thread (4 messages) 4 messages, 2 authors, 2013-09-16

Re: Weirdness with DDF arrays (mdadm 3.3)

From: Martin Wilck <hidden>
Date: 2013-09-16 17:02:27

On 09/16/2013 03:47 PM, Francis Moreau wrote:
[...]
quoted
quoted
quoted
Wrt loop1[2], I think you interpret the [2] wrongly. It seems to be the
kernel index of the device somehow. The mdstat parsing code of mdadm
doesn't look at this number. If you look at
/sys/class/block/md124/md/dev-loop*/slot, the number should be correct -
I tried it here.
Well I think I interpreted the numbers the way it's described here :

https://raid.wiki.kernel.org/index.php/Mdstat#md_device_line
That description is not quite correct. The number in brackets [2] means
the index of the disk in the meta data (for DDF, that's the index in the
"physical disks" table of the container). That number isn't very
meaningful except for the meta data itself.

The logical disk index is represented by the "slot" attribute in sysfs.

See e.g.
http://lxr.missinglinkelectronics.com/linux+*/drivers/md/md.h#L79

The number displayed in /proc/mdstat is "desc_nr", while the number that
actually matters is "raid_disk".
Maybe the description in the wiki is correct but there's a bun in the
kernel which displays the wrong number ?

If "desc_nr" isn't meaningful, I don't see the point to show it in
/proc/mdstat.
Well, we could propose to change the value displayed by the kernel. The
question is whether the kernel maintainers would allow that, because it
would change the kernel-userspace API. mdadm itself doesn't look at this
number, but other tools might, so there is some small but non-zero risk
of breaking something somewhere.

Let's wait what others have to say.

Martin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help