On Tue, Feb 24, 2004 at 08:54:10PM +0100, christophe varoqui wrote:
> Kevin Corry wrote:
> >>if test IO succeeds, exec the multipath config tool for this path, which
> >>will reset all paths for the multipath to their active state.
> >
> >Will this reactivate *all* paths, or just the path that's known to have
> >recovered?
> >
> *all* :)
> like the initial config does ...
> yes, it is suboptimal, but how disturbing ? I don't even know how to
> activate individual paths. Maybe with path options in tha path list of
> the PG definition ?
<SNIP>
It will be extremely disturbing because we'll take SCSI timeout handling
adding multi-second delays until we get the errors reported in order to
fail an erroneosly activated path again. During this fs/appls will starve.
Imagine the case, where the first path (P1) in a priority group is long-term
dead and gets reactivated after the test thread found another arbitrary group
member (Px) came back to life. In a larger group with flaky paths this scenario
will render the group effectively useless.
There's 2 options to solve this:
a) load a different table which avoids the long-term dead path;
IOW: which only contains paths we know to be operational
b) have an interface change to be able to flag a path inactive
which will prevent io from getting queued
a obviously avoids an interface change at the cost of holding different tables
in the mpath config tool and the driver.
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat GmbH
Consulting Development Engineer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@xxxxxxxxxx +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
