On Thursday April 9, dledford@xxxxxxxxxx wrote:
> On Apr 8, 2009, at 3:31 AM, Neil Brown wrote:
> >
> > And you are saying that if we uncomment the "#ENV{...." line, then we
> > only want it to fire on add devices. So something like:
> >
> > ....
> > ACTION!="add|change", GOTO="md_end"
> > +ACTION=="change", GOTO="no_incr"
> >
> > # import data from a raid member and activate it
> > #ENV{ID_FS_TYPE}=="linux_raid_member", IMPORT{program}="/sbin/mdadm
> > --examine --export $tempnode", RUN+="/sbin/mdadm --incremental
> > $env{DEVNAME}"
> > # import data from a raid set
> > +LABEL="no_incr"
> > KERNEL!="md*", GOTO="md_end"
> > ......
> >
> > Is that correct?
> >
> > Your explanation certainly seems reasonable.
>
> As I was reading through this, I certainly thought the above
> implementation was reasonable, and then I got this new bug report:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=495034
I'm guessing this bug is because the line
TEST!="md/array_state", GOTO="md_end"
is missing from the udev rules file?? It is a relatively recent
addition.
>
> I would do some investigation on your own machines, but given udev
> change semantics, I think the proper course of action is simply to not
> watch changes.
We absolutely have to watch change events on md devices.
When the "new" event happens, the array doesn't exist yet. We have
just started building it. Once it is fully assembled and started a
change event happens and it is on that event that we create /dev
files, look for partitions, and mount filesystems.
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
