multipath-tools does check all paths. But when it finds that a path previously active has failed, it never tells the kernel about it. (Reported by Edward.)
Candidate fix in 0.4.5-pre2 Please confirm the new behaviour is what is expected.
Hm, I just tried 0.4.5-pre2, but it doesn't appear fixed... After doing a switch port disable, multipathd path checker detects the 2 paths are down, but the internel dm path state is still 'active'. I would expect it to go to 'failed'. 1IBM 2105 739FCA30 [size=953 MB][features="1 queue_if_no_path"][hwhandler="0"] \_ round-robin 0 [enabled][first] \_ 1:0:0:1 sdbn 68:16 [ready ][active] \_ 1:0:1:1 sdbv 68:144 [ready ][active] \_ 0:0:0:1 sdb 8:16 [faulty][active] \_ 0:0:1:1 sdj 8:144 [faulty][active]
The framework is in place, certainly needs debugging now : multipathd/main.c:checkerloop() calls fail_path(), which calldm_fail_path() upon path going down events. I just verified the log received the "checker failed path %s in map %s" message when removing a path through sysfs. If you don't beat me to it, I'll see what I can do tomorrow.
Hi Christophe, It turns out that dm_fail_path() is never being called in my setup because the check for !pp->mpp always fails. Not sure why you removed the intial multipath reconfiguration from multipathd (in patch below), because otherwise, the multipath maps are not created. And as you removed the signal handling, moving to uevents I believe, I'm not quite sure how the multipath daemon's allpaths gets updated when multipath is run. It looks like uevent is triggered only when removing/adding underlying sd devices? I also get this odd behavior that multipathd process will just die on me if I try to restart it when there are already maps configured. Not sure why, as I see no debug messages. (BTW, I was running 0.4.5-pre2 on the RHEL4 U1 beta1 kernel.) --- multipath-tools-0.4.5-pre2/multipathd/main.c 2005-04-28 16:52:56.000000000 -0700 +++ multipath-tools-0.4.5-pre2-patched/multipathd/main.c 2005-05-03 05:50:47.203453424 -0700 @@ -468,7 +471,7 @@ } log_safe(LOG_NOTICE, "initial reconfigure multipath maps"); -// execute_program(conf->multipath, buff, 1); + execute_program(conf->multipath, buff, 1); while (1) {
> And as you removed the signal handling, moving to uevents I believe, > I'm not quite sure how the multipath daemon's allpaths gets updated when > multipath is run. It looks like uevent is triggered only when > removing/adding underlying sd devices? multipath is run from hotplug/udev, and only for "add"s. For each hotplug "add" event, the daemon will receive a "add" uevent. The signal thing was safe to kill. As for the initial multipath run, if your hotplug/udev setup is right, you don't need it : the maps should already be configured when starting the daemon. Even if your setup has multipath.dev disabled, you'd better put the multipath run either in intrd or in multipathd startup script. Now, multipathd dying on you needs to be fixed. But as far as I can see the design directions are right.
Commit http://kernel.org/git/gitweb.cgi?p=linux/storage/multipath-tools/.git;a=commit;h=a6e90b703b6c9a9a38d481a8fe4e82085ad247cc and http://kernel.org/git/gitweb.cgi?p=linux/storage/multipath-tools/.git;a=commit;h=e6b86e3673321852b68496d25d1a081f30d6d21b should fix it. My bad.
MODIFIED means it should be fixed but we're awaiting confirmation of that. If there are no comments in a week or so, then we assume it is fixed and close the bug. If subsequently it's found not to have been fixed, then we simply reopen it.
Using the multipath-tools git snapshot from May 16, 2005. Without any I/O running, I disabled a port (bringing down half the paths for each multipath device), and the state of the disabled paths were correctly put into '[faulty][failed]' state. However, I also just tried this on the May 26 git snapshot, and it doesn't work anymore. It seems that multipathd keeps dying whenever I try to start it up using RH4, U1's '/etc/init.d/multipathd start' script. Not sure what's going on. (I'm using RH4 U1 beta 2.6.9-9.ELsmp kernel.)
> > Instinctively I would say I messed the case where no "failback" keyword > is provided in the config file, meaning the culprit is the last commit. > Just checked out the latest from the git repository and tried failing paths with and without I/O running. The paths are failed and recovered as expected under both scenarios. Thanks Christophe.
Closing as per previous comment.