On 11/25/2009 10:53 AM, Hans de Goede wrote:
> Hi,
>
> Patch 1-3 look good.
>
> On 11/25/2009 04:25 PM, Peter Jones wrote:
>> This brings up multipath devices which are configured in multipath.conf
>> as we find them.
>> ---
>> modules.d/90multipath/14-multipath-scan.rules | 9 +++++++++
>> modules.d/90multipath/install | 3 +++
>> modules.d/90multipath/multipath-scan.sh | 16 ++++++++++++++++
>> 3 files changed, 28 insertions(+), 0 deletions(-)
>> create mode 100644 modules.d/90multipath/14-multipath-scan.rules
>> create mode 100644 modules.d/90multipath/multipath-scan.sh
>>
>> diff --git a/modules.d/90multipath/14-multipath-scan.rules
>> b/modules.d/90multipath/14-multipath-scan.rules
>> new file mode 100644
>> index 0000000..b4acf57
>> --- /dev/null
>> +++ b/modules.d/90multipath/14-multipath-scan.rules
>> @@ -0,0 +1,9 @@
>> +# scan for multipath devices
>> +SUBSYSTEM!="block", GOTO="end_mpath_scan"
>> +KERNEL!="sd*", GOTO="end_mpath_scan"
>> +PROGRAM=="/bin/sh -c 'for i in //holders/dm-[0-9]*; do [ -e $$i ]&&
>> exit 0; done; exit 1;' ", GOTO="end_mpath_scan"
>> +RUN+="/sbin/modprobe dm-multipath"
>> +RUN+="/bin/echo 'queuing multipath scan'"
>> +RUN+="/sbin/initqueue --settled --onetime --unique --name=mpscan
>> /sbin/multipath-scan"
>> +RUN+="/bin/sh -c '>/tmp/.multipath-scan-%k;'"
>> +LABEL="end_mpath_scan"
>
> Hmm, I just realized something, this rule will keep on triggering if a
> disk is
> not part of a multipath setup. As in that case it will never become a
> holder
> of a device mapper device.
>
> And since things like opening /dev/sda rw (which /sbin/multipath might
> very well do), trigger a change event, this feels like an infinite loop
> to me.
It does not trigger a change event.
> Maybe this rule should have a
> ACTION!="add", GOTO="end_mpath_scan"
>
> ?
>
> I think it would be best to discuss this with Harald.
>
> Regards,
>
> Hans
--
Peter
"I can imagine a world without war, without hate. I can imagine us
attacking it, because they'd never expect it."
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
