On 2004-11-05T22:39:56, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > It's worth trying something along those lines to see if it shifts the > complexity to a better place. > > [BTW The bypass lots at once issue is trivially solved by > accepting a list of PGs.] True. But then, which PG would you try first from the list of bypassed ones, if all are bypassed? (Either because user-space told us to, or because the error handler did it; doesn't matter much.) Right, right now the code would pick the first PG with healthy paths. Actually, this is quite similar to the point you raise below. > So it removes enable/disable PG messages, and replaces them with a > single message to switch PG to a specific PG immediately. > PGs become 'sticky' - the current_pg will no longer change > automatically if a path in a higher-priority PG becomes available. Right. > But what happens if the error handler requests a PG switch? > Does that mean that PG cannot be used again without userspace > intervention (in which case it might as well fail all its paths)? > For otherwise, how is that state held (and reported/modified by userspace) > without something similar to the bypass logic? See above. This isn't different from the "all PGs are bypassed, which one to use now". We chose the first one. That's the lengthy paragraph in parentheses I had in my mail about getting fancy about which PG to pick when we switch PGs in-kernel. The truth is that for the active/passive scenarios, there'll be exactly two PGs, and this problem doesn't arise - the answer is "the other one!" in any case, or "try reinitializing ourselves if we are the last PG with healthy paths standing". I've reached the conclusions (which one might disagree with) that - a this problem is a redherring and doesn't actually exist in >95% of the target scenarios, if at all. - The problem is not addressed by the bypassed flag any better than it is by the suggested approach, and switching to the highest priority PG with healthy paths just does it as well. (Which essentially gives user-space a chance to influence this with a static list of priorities when the table is loaded.) - If the problem _does_ exist it thus will need something more fancy anyway, but that I'm for the reasons given above not too eager to spend time designing something complex nobody has any use for yet and might never have, and that (s)he who needs it can then add it by a feature flag in some future version. (ie, providing a pick_pg function somewhere akin to the path-selector with hw-handler tie-ins.) At least, that's my reasoning ;-) Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business