On Thu, Apr 23, 2009 at 07:05:04AM -0400, Doug Ledford wrote:
# This file causes block devices with Linux RAID (mdadm) signatures to
# automatically cause mdadm to be run.
# See udev(8) for syntax
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member",
\
IMPORT{program}="/sbin/mdadm --examine --export $tempnode", \
RUN+="/bin/bash -c '[ ! -f /dev/.in_sysinit ] && mdadm -I
$env{DEVNAME}'"
i believe i saw this as well, but not at startup, it was when i manually
run mdadm -As, so while your hack to prevent udev from assembling
devices while in sysinit may not be a full solution.
No, it is. In your situation, the rules line must have read
ACTION="add|change". The fact that the incremental assembly rule would
you are probably right about that, i tried with your ruleset and it
looks like the problem was due to the change ACTION
just out of curiosity what is the use of the IMPORT statement, is it
needed by some other rule?
my solution was "rm -f /etc/udev/rules.d/70-mdadm.rules",
works like a charm :P
probably the best solution is preventing concurrent mdadm rules with a
lock.
do you think the last suggestion of having mdadm protect from itself
would be of use?
I think it might still happen when stacking arrays
i.e. mirror of stripes
running mdadm -As would activate the first striped md and generate and 'add'
event, then while it is assembling the second one udev will trigger and
create a degraded mirror containing only the first one.
Regards,
L.
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
--
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
