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

[Alasdair G Kergon]

On Fri, Nov 05, 2004 at 11:53:49PM +0100, Lars Marowsky-Bree wrote:
> 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.)

The current algorithm is simple - the one with the highest priority.
i.e. if all PGs are bypassed, the code simply behaves exactly as if
there never had been any bypass logic added.

> > 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.
 
But what if *that* one now also says 'switch_pg' ?
Currently, we go back to the first one and if it says 'switch PG' again,
we start failing its paths, so we have a finite process:
A PG can only say 'bypass me' once - after that its paths will be
failed forcibly.  And the logic is simple and transparent.

The new way still needs a flag against each PG to indicate that it
said 'switch_pg'?

> "try reinitializing ourselves if we are the last PG with
> healthy paths standing".

But *something* is needed to cope with all the pg_init_fns 
always returning 'switch_pg', which would mean there never
was just one 'last PG with healthy paths standing'.

I'm attracted to making the PGs sticky by default, and adding
a 'switch_pg' message from userspace, replacing the ability
to set/reset the bypass flags.  (A switch_pg message would
reset all the bypass flags.  They'd be reported to
userspace, but the only reason for userspace needing to 
change them would be to facilitate testing i.e. no need
for multipath tools to ever change them.)

Alasdair
-- 
agk at redhat.com