multipath: delegate dangerous commands to multipathd
authorMartin Wilck <mwilck@suse.com>
Sat, 13 Jan 2018 21:19:20 +0000 (22:19 +0100)
committerChristophe Varoqui <christophe.varoqui@opensvc.com>
Wed, 7 Mar 2018 08:27:50 +0000 (09:27 +0100)
commit506d253b7f89806cb62a37d8854e145aee2be7df
tree007384e9438428c70f8576184fcac310e992b9a7
parentd11a6f5aabf8c4b7d3b5864dcc6869f89e18382a
multipath: delegate dangerous commands to multipathd

Some multipath commands are dangerous to run while multipathd is running.
For example, "multipath -r" may apply a modified configuration to the kernel,
while multipathd is still using the old configuration, leading to
inconsistent state between multipathd and the kernel.

It is safer to use equivalent multipathd client commands instead.
For now, do this only for "multipath -r", but other invocations
may be added in the future. Perhaps some day, all "multipath"
commands will be mapped to multipathd actions.

Note that with delegation, "multipath -r" will not produce any
terminal output, so this may affect users who capture "multipath -r"
output for parsing it. It would be very hard to produce compatible output
to the normal multipath command for different verbosity levels. I
considered running "show topology" after "reconfigure", but the output
would have slightly different format and would only match -v2, anyway.

I plan to convert more multipath commands, but that needs some more
thought. Some additional multipathd client commands need to be
implemented first.

Changes wrt v2:
 - use libmpathcmd rather than exec'ing multipathd (Ben Marzinski)
 - pass more parameters from main program, preparing for other commands
Makefile.inc
multipath/main.c