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

From: Lars Marowsky-Bree <lmb suse de>

To: device-mapper development <dm-devel redhat com>

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

Date: Fri, 5 Nov 2004 23:53:49 +0100

On 2004-11-05T22:39:56, Alasdair G Kergon <agk 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 suse de>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business