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

[christophe varoqui]

Le mardi 02 novembre 2004 à 23:43 +0100, Lars Marowsky-Bree a écrit :
> On 2004-11-02T23:22:04, christophe varoqui <christophe.varoqui at free.fr> wrote:
> 
> > Is the following example illustrates what you have in mind ?
> > 
> > | pg1 | pg2 |	pg1 maps paths to ctr1, pg2 - ctr2
> > ====================================================================
> > | A A | A A |	paths in pg2 are marked A but are unusable
> > | F F | A A |	ctr1 shuts down, ctr2 takes over, now pg2 paths
> > 		are really up, maybe with a little help from
> > 		pg_init_fn. Event is caught by multipathd
> 
> This is not what would happen in the model proposed by Alasdair and me,
> or at least not the case which we're discussing.
> 
> This is what would happen if all paths in PG1 were really _failed_. But
> that's still an interesting scenario to discuss, obviously.
> 
This is likely what would happen anyway, because chances are that all PG
paths will be tried *before* userspace is given to opportunity to
disable the PG.

> > The current model being :
> > ====================================================================
> > | A A | A A |	paths in pg2 are marked A but are unusable
> > | F F | A A |	ctr1 shuts down, ctr2 takes over, now pg2 paths
> > 		are really up, maybe with a little help from
> > 		pg_init_fn. Event is caught by multipathd
> > | A A | A A |	multipathd swaps pg1 and pg2, ctr1 paths are marked up
> > 		by the table reload
> 
> The swapping has the problems Alasdair points out though. The low-memory
> behaviour and the loss of all state. That we sent a superfluous pg_init
> in that case wouldn't be too bad I guess.
> 
> But it would imply that multipathd had to keep more state about which PG
> is the default one (or parse more status from the DM tables). In the
> model with the "bypassed" PGs, the default one would always be the first
> PG, even if using the other one.
> 
This is the purpose of PG policies layering in multipath, and it is
stateless. Well, it uses path states obviously, but doesn't have to
remember anything.

This logic is needed anyway for assembling the maps right the first
time. So it is not added compexity to reuse it to arbitrate failover
cases.

> This would make the mapping more readable for the admins, too.
> 
I thought I was to one militating for simple maps :)

> Userspace which is already running though and locked into memory, and
> thus shouldn't be affected by the low memory condition either.
> 
The daemon doesn't use a memory pool and uses callbacks extensively. I
still havn't got any feedback about the effect of storing those
callbacks on a ramfs like multipathd does.

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