On 01/04/2012 10:10 PM, Laurent Bigonville wrote: > Sorry for the delay, I'm not working on that system (but Frido that has > posted above does). > > As I was suspecting, this is an issue with "something" (udev I guess) > poking the inactive path(s). Loading the kernel multipath driver makes > the kernel aware of the fact that the path is inactive. Yes, looks like that's the case. I never saw this in my tests because here it is all NetApp and we don't use a hardware handler.
> I guess that Frido's script (or something similar) should be added in
> the main multipath-tools package (and not only in the -boot variant).
>
> What do you think?
If the hardware handler is set in the multipath.conf file, the
corresponding driver will be loaded. Yes, there will be a timing catch
on when the device discovery triggers (which in almost all cases will be
way before the start-up of multipathd daemon) and when the multipathd
daemon starts.
So this problem applies in both the cases.
We could either decide to run multipathd from within initrd. We'll still
need to ensure that every modification to multipath.conf does propagate
to initrd also.
OR
Load all the handlers. Not the one that I like.
The simplest I can think of is to document these things, at least in
README.Debian. Just ensure to load the hardware handler module for your
storage array. Such things can go into /etc/modules.
22:19:45 rrs@champaran:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
firewire-sbp2
loop
Let me know your views.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
