Starting with the 0.7.7 release of the multipath tools, the multipath
udev rules always set a value in ENV{DM_MULTIPATH_DEVICE_PATH} for any
device that multipath scans. A value of 0 means that the device is not
claimed by multipath, and a value of 1 means that it is. Because of
this, udev rules that check ENV{DM_MULTIPATH_DEVICE_PATH}=="?*" will
always return True, and act as if every scanned device is claimed by
multipath. Checking ENV{DM_MULTIPATH_DEVICE_PATH}=="1" will work
correctly for both the old and new versions of the multipath tools.
There is no point trying to delete partitions; dmraid works
happily even with them. On the contrary trying to delete partitions
can even be harmful when eg dmraid should _not_ be started.
References: bsc#998860
Signed-off-by: Hannes Reinecke <hare@suse.com>
This is a more sane solution, than ignoring subsequent "change" events.
The only danger is that we could loop, if a lvm scan triggers a broken
md partition, which triggers a broken PV and so on.
Better fix the scanning tools, not to emit change events for devices,
if no action was taken.
Intel BIOS raid is being shifted from dmraid to mdraid because mdraid offers
more features. So if an imsm metadata capable mdadm is present use mdraid
instead of dmraid for isw_raid_member's
This patch also adds code to mdraid_start.sh so that the raidsets
inside the imsm containers get started once udev is done probing
(doing this earlier leads to potentially degraded use of the sets and
an unwanted resync).
Benjamin Marzinski