On Wed, May 15, 2013 at 8:41 PM, NeilBrown <neilb@xxxxxxx> wrote: > 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'. > Excellent points. Yes it would be a sort of an API change which would not be good for people who depend on it to act that way. That is sort of how I ended up "caring so much" about it in the first place. 0.90 metadata behaved one way and now 1.X behaves differently so I need to update some tools to take that into account. Before I updated the tools I wanted to make sure it wasn't a "bug" and something that you wanted to fix. If it was then I would possibly try to pull in the kernel patch rather than change the tools. > > 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. > This looks nice but I wouldn't discount the value of /proc/mdstat. If monitoring tools check the status of raid often then I would rather them use file I/O of a file maintained by the kernel rather than running a command each time and parsing output. Thanks for collaborating with me on this. I'll update my tools. Dusty Mabe -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
