Re: what is the current utility in testing active paths from multipat hd?

[Lars Marowsky-Bree <lmb@suse.de>]

On 2005-04-27T11:17:02, Mike Anderson <andmike@us.ibm.com> wrote:

> 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.

ACK. Yes, this is part of the additional information to use I was
referring to. As long as the port is down, why bother...

> > 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).

Yes, it's easier, but it also slows down responsiveness and path
reactivation of course. One can argue that the combination of the two
works; we only retest every path every N seconds, but we interleave
them, so that essentially we test a path every N/M seconds; and as soon
as one path finds a state change, we shorten the timers for all paths so
they get all tested faster.

That's probably a pretty sophisticated heuristic which would work
reasonably well w/o any additional configuration.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business