[dm-devel] proposed changes to multipath-tools

[goggin, edward]

Christophe and I have re-designed the multipath-tools package to enable
multipathd(8) to be self sufficient without multipath(8).

Design Change :
===============
multipathd(8) now configures paths/devices directly in response to
uevent or UNIX domain socket driven path addition/removal and mapped
device addition/removal/rename external events without requiring
a hotplug invocation of multipath(8) or any other executable/shell
to accomplish these tasks.

Rationale :
===========
This design approach is more efficient than the previous one
involving hotplug invocation of multipath since 

(1) it does not involve fork&exec

(2) it does not require that a host's entire multipath path state be
    reconstructed upon the occurrence of each event

(3) this design approach will eventually lead to the elimination of
    the file based path cache currently used by multipath(8) to
    improve the response time of frequent path management invocations

(4) since this design approach consolidates multipath state management,
    synchronization of updates to the multipath configuration become
    more easily achievable

(5) multipathd(8) is now able to respond effectively to the hotplug
    removal (restoration) of failed (reactivated) paths to SCSI
    logical units initiated by the common SCSI transport classes
    (fiber channel, iSCSI) introduced at or about the 2.6.13 kernel

Consequences for users and packagers :
======================================
As part of this effort, a significant amount of code previously
private to either the multipath(8) or multipathd(8) executables
has been moved to libmultipath where it is easily sharable between
both executables.  Although multipath(8) will continue to be
capable of setting up the multipath configuration (particularly
during early boot), its use to perform multipath configuration
duties beyond early boot is no longer required.

While these changes will likely be first introduced in version
0.4.7 of multipath-tools, at least the functionality for multipathd(8)
to be responsive to the externally initiated renaming of a multipath
mapped device is dependent on a kernel patch which is likely
destined for 2.6.15.

Also, please remember that while the invocation of multipath(8) via
hotplug is no longer necessary (or desirable at this point), the
hotplug invocation of kpartx(8) is desirable.  To affect this, please
do not remove the multipath udev rules file at
/etc/udev/rules.d/multipath.rules, but instead simply comment out
the invocation of multipath(8) upon the occurrence of a hotplug add
event for a target device.

Near-term plans :
=================
Continue enhancing multipath-tools to

(1) broaden the capability to selectively update the components of
    a multipath map

(2) enhance the capabilities of the multipathd(8) client interface.

An improvement in the first category is the configuration support for
adding/removing/changing any component of a multipath map, particularly
adding/removing a single path or path group, to a multipath map without
having to reload a new map and changing multipathd to take advantage
of this new support.  Much of this work will require commensurate
kernel changes to the multipath target driver.  An improvement in
the second category is the enhancement of both the "list paths" and
"list maps" multipathd(8) client commands to have "at least" the
capability of a "multipath -l" display.

Longer-term plans :
===================
Adapt multipath-tools to utilize whatever new device mapper event
mechanism and/or configuration passing mechanism gets implemented
with the goal of having multipathd be capable of 

(1) selectively updating either the contents or status of any
component of a multipath map

(2) being alerted via a kernel generated event whenever either any
component of the map is changed or the status of any map component
changes.