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

[Lars Marowsky-Bree]

On 2004-11-03T00:14:48, 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.

You may have misunderstood this then. 

The kernel parse the error code it receives from the IO on the path and
knows it has to bypass that PG. It won't fail the path, it will switch
the priority group directly.

> > 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.

Yeah, well, but this probably needs fixing anyway eventually. So this is
not a new problem.


Sincerely,
    Lars Marowsky-Brée <lmb at suse.de>

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