[dm-devel] 2.6.10-rc1-udm1: multipath work in progress

[Lars Marowsky-Bree]

On 2004-11-05T22:39:56, Alasdair G Kergon <agk at redhat.com> 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 at suse.de>

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