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

[christophe varoqui]

Le mardi 02 novembre 2004 à 18:03 +0100, Lars Marowsky-Bree a écrit :
> On 2004-11-02T17:49:12, christophe.varoqui at free.fr wrote:
> 
> > > Sort of. However the kernel definetely needs an additional way to switch
> > > PGs w/o failing all paths in one, and for user-space to notice that this
> > > has occured.
> > I still can't see why it is needed : what's wrong with trying and fail on all
> > paths in a path group because trying the next PG ?
> 
> Because it's wrong? Something may have caused a switch-over to the other
> PG.
> 
> (Something being an administrative intervention or some program on the
> same or even another node, or the device itself due to a rolling
> firmware update.)
> 
> The paths are _not_ failed. It's just that we have switched to the other
> priority group.
> 
Let the kernel fail them ... as soon as the primary PG paths are
exhausted, it will switch to the secondary PG and an event will cause
multipathd to reconfigure the table. The secondary will become primary,
and failed paths will come back up, grouped in a low prio PG.

> Failing the paths is _wrong_. We _could_ force a failback to the PG if
> we found that we had no other path in the other PG (because all of them
> have failed, for example.)
> 
We can failback already, with the current design.
As I see it, all the "disable PG" feature brings is save some table
reloads. Is it worth the added complexity ?

> A PG not being active is _distinct_ from a PG having no healthy paths.
> 
> If and when to coordinate the switch-back to the default priority group
> is a user-space issue.
> 
Our disagreement here seems to come from your wanting to do predictive
switch-over, and my arguing that if we have a good "reactive behaviour",
we'll be safe with it in any case.

I personnaly trust the device-mapper and multipath-tools' reactive
behaviour. Until now the design is simple and I still don't see its
limitations.

> > Performance is definitely not  an issue there. Reliability is, and a
> > simple API is the key to reliability.
> 
> Make everything as simple as possible, but no simpler.
> 
Let us not slip into a moto battle :)

Please believe we will eventualy settle for a direction. I'm not trying
to have the last word here.

regards,
-- 
christophe varoqui <christophe.varoqui at free.fr>