On Thursday October 25, dmiller@xxxxxxxxx wrote:
> Neil Brown wrote:
> > It might be worth finding out where mdadm is being run in the init
> > scripts and add a "-v" flag, and redirecting stdout/stderr to some log
> > file.
> > e.g.
> > mdadm -As -v > /var/log/mdadm-$$ 2>&1
> >
> > And see if that leaves something useful in the log file.
> >
> >
> I haven't rebooted yet, but here's my /etc/udev/rules.d/70-mdadm.rules
> file (BTW - running on Ubuntu 7.10 Gutsy):
>
> SUBSYSTEM=="block", ACTION=="add|change",
> ENV{ID_FS_TYPE}=="linux_raid*", RUN+="watershed -i udev-mdadm
> /sbin/mdadm -As -v > /var/log/mdadm-$$ 2>&1"
Yes, that would do exactly what you are experiencing.
Every time a component of a raid array is discovered, it will try to
assemble all known arrays.
So one drive appears, it tries to assemble the array but there aren't
enough so it gives up.
Then two drives. Chances are there still aren't enough, so it gives
up again.
Then when there are three drives it will successfully assemble the
array - degraded.
Then when there are 4 drives, it will be too late. I cannot see why
that would lead to the "cannot update array info" error, but it
certainly explains the rest.
That is really bad stuff to have in udev.
The "--incremental" mode was written precisely for use in udev. I
wonder why they didn't use it....
Maybe you should log a bug report with Ubuntu and suggest they discuss
their udev scripts with the developer of mdadm (that would be me I
guess).
NeilBrown
-
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
