Lars Marowsky-Bree [lmb@xxxxxxx] wrote: > On 2005-04-27T12:27:32, "goggin, edward" <egoggin@xxxxxxx> wrote: > > If not, it may be possible to significantly reduce the cpu&io > > resource utilization consumed by multipathd path testing on > > enterprise scale configurations by only testing those paths > > which the kernel thinks are in a failed state -- obviously a > > much smaller set of paths. > > I could see not testing paths if we knew IO was hitting them; as an > approximization, the active paths from the active PG might be omitted. > However, the paths in the inactive PG all need to be tested, or else you > are never going to find out that the paths have gone bad on you until > you try to failover. > > The best way to minimize path (re-)testing needed is to figure in the > hierarchy of components involved; as long as the FC switch is still bad, > there's no point testing any target which we could reach through it, > etc; testing whether the switch itself is healthy would round-robin > through our various connections to the switch, to make sure we don't > declare the switch down because we got hung up on one failed path. > Once support gets completed / utilized the fc_transport class should provide data on the link state and the port state which could be provide indication of path health for deciding if to send a patch check cmd. This would add complication to the tester as each new transport would need some type of handler. > Another option would be to not mechanically test every N seconds, but to > retest a failed path after 1s - 2s - 4s - ... 32s max as a cascading > back-off, and maybe start at 2 - 64s for paths in inactive PGs. > A cascading backoff / staggered timer would require less topology knowledge than the above path health testing method and would provide the reduce IO loading desired (depending on how high a user was willing to go on setting the delta between path tests). -andmike -- Michael Anderson andmike@xxxxxxxxxx