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

[Lars Marowsky-Bree]

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.

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

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.

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


> the rescan is not needed per-se, but the device size should be updated
> after the START_STOP because the initial READ CAPACITY failed on boot.
> I would guess rescan is the easiest way to do that.

Ok, that's a good point.


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

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company