Hello, here goes multipath-tools-0.3.4 Many structural change, consequences of the Suse review. Highlights are : * glibc compilation, uses system libraries where possible * multipath & multipathd now use the same path checkers. Consequence being multipath now need sg loaded * checkers now can return more than UP or DOWN and they take 2 more arguments : * msg : to let the checker pass log mesg to the core * context : a persistent data store the checkers can use at discretion * multipath pgpolicies rework : I broke the group_by_serial LUN balancing. This is volontary : I'd like someone affected to come up with a callout binary to do the balancing based on the priority framework. Full ChangeLog for the release : * [multipathd] exec multipath precisely : pass in the path or the devmap to update. No more full reconfiguration, and really use the reinstate feature of multipath. * [multipathd] check all paths, not only failed ones. Path checker now trigger on state change (formerly triggred on state == UP condition) * [multipathd] incremental updatepaths() instead of scrap / refresh all logic. * [multipathd] path checkers now take *msg and *context params. consensus w/ lmb at suse. tur.c modified as example * [multipath] assemble maps in PG vector descending order to fit the layered policies design * [multipath] stop playing with strings in pgpolicies, as it uses more memory and looses info for no gain * [multipath] remove lk2.4 scsi ioctl scsi_type remnant * [multipath] layered pgpolicies : (see pgpolicies.c) * group_by_status * group_by_serial | multibus | failover | group_by_prio * sort_pg_by_summed_prio thus remove duplicated failedpath logic in pgpolicies * [checkers] framework for arbitrate checkers return values * [multipathd] scrap yet another reinvented wheel in the name of the LOG macro : learn the existance of setloglevel and LOG_UPTO macro * glibc make with "make BUILD=glibc", asked by lmb at suse As usual, doc and download at : http://christophe.varoqui.free.fr/ regards, -- christophe varoqui <christophe.varoqui@xxxxxxx>