[dm-devel] [RFC] multipathd recent evolutions

[christophe varoqui]

Well, the git HEAD has seen quite a lot of multipathd structural changes
recently. It has come to a point where I would like to collect reviews
and opinions about the direction I'm heading to.

These directions are :

1) suppress the multipath -> multipathd signaling

Replaced by a uevent listener in the daemon which gathers events at the
source, benefiting from full info rather than a generic signal.

The listener reacts on 4 event types :

o path add : start checking this path
o path remove : stop checking this path
o multipath map add : start listening to DM events for that map
o multipath map remove : stop listening to DM events for that map

This new model brings a lot of clean ups at the code level too :

o kill all inter thread signaling
o kill the wait_thr altogether, with all its waiter vector housekeeping,
since DM event waiter thread data blobs are now embedded into struct
multipath

2) suppress all multipath configurator execs from the daemon.

The daemon is now a lot more predictable, as we now for sure it can only
reinstate path or switch group. The daemon can no longer be responsible
for a map reload.

As a result, the reinstate code path, now being fork/exec-free, can now
be fine tuned as a critical path for "return to service in adverse
situation" scenarii.

The checker logic now is : upon path state change from "down" to "up" 

o reinstate the path
o if daemon driven failback is selected, compute the path groups prio
and do the failback. Deffered failback was asked by Lars and could be
added quite easily now.


That's it. I expect there will be some glitchs here and there, but the
HEAD is quite stable for me in ISCSI testing/torturing.

Hope to receive sizeable reviews and comments.

PS: Edward, Dave, I updated
http://christophe.varoqui.free.fr/graphics/macroflux.png to reflect
these changes if you are interested in merging it in the OLS paper.

Regards,
-- 
christophe varoqui <christophe.varoqui at free.fr>