Piergiorgio Sartor wrote:
Removing the /dev/md/ device files does nothing of value. However, I
From what I saw with udevmonitor, it seems that,
with those files, there is no add event.
Few remarks:
'add' uevent will happen only, if created or assembled array uses kernel
name not yet used (in the other words, it's not present under
/sys/block/ yet).
Actual assembly and removal cause only 'change' uevents.
Moreover - if you have partitions on the raid device, access to the
device (usually any mdadm udev rules will trigger it due to e.g. vol_id,
etc.) will trigger sequence of additional partition 'add' uevents.
If you issue mdadm -S, 'change' is issued for the block device, but if
you have any md partitions on such array - 'remove' uevents for them
will happen when another arrary (possibly the same) is created or
assembled using the same kernel name. OR - you can for example issue
blockdev --rereadpt /dev/md... to trigger 'remove' partition uevents
manually and immediately.
'remove' for actual raid device will not happen. Mdadm doesn't do it
(recalling my old discussion with Neil, it's due to some subtleties, and
coding it it's just not worth the effort, at least not for 2.9.x). So
- you're left with inactive /dev node and /sys/block entry.
Still, if all your arrays and stoped, and e.g. you issue rmmod raid1 (if
we talk about raid1 arrays for the sake of the example) - that would
cause 'remove' uevents of course.
This is all nicely visible under udevd --debug - you might need to
simplify your rule files in a few places to control the clobber though.
Michal
--
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
