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