In the past without knowing exactly why I have experienced failed
assemblies upon a reboot. I have seen correction in this behavior by
properly populating my /etc/mdadm/mdadm.conf file.

I typically log in as root and do this:

mdadm --examine --scan --config=mdadm.conf >> /etc/mdadm/mdadm.conf

Clean up is typically needed.

So could this be an indication that my super-blocks on this particular
array have some discrepancies? Notably the hostname?

I tend to worry about my daters incessantly...

On Thu, Jun 3, 2010 at 4:42 AM, Christian Gatzemeier
[off-list ref] wrote:

Andrew Dunn <andrew.g.dunn.dod <at> gmail.com> writes:

quoted

What is the meaning of Preferred Minor : 2 ?

Most of the time that array will get assembled as md2, but conflicts,
other numbers and errors stemming from differently assembled arrays can
occur.

From https://wiki.ubuntu.com/ReliableRaid:
"Mdadm is setting up arrays according to unreliable superblock
information. (Device "minor" numbers, labels and hostnames in
superblocks are not sure to be unique and can be outdated.) This is
combined with the idea of fixing the unreliability by limiting array
assembly with information from mdadm.conf. (Defining PARTITIONS, ARRAY,
HOMEHOST lines.) Consequently this forces setup tools, admins and
installers to create mdadm.conf files and subjects them to the exact
same reliability problems."

I guess this conflict prone behavior is mostly legacy behavior from the
past, or is there still an apparent reason to expose dynamic kernel
internals like the minor to userspace instead of basing device node name on
"md-UUID"?

Regards,
Christian


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html