Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155546 - multipath-tools could benefit from more cmdline options
Summary: multipath-tools could benefit from more cmdline options
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ben Marzinski
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-21 11:25 UTC by Lars Marowsky-Bree
Modified: 2011-02-14 21:42 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2011-02-14 21:42:36 UTC

Attachments (Terms of Use)

Description Lars Marowsky-Bree 2005-04-21 11:25:17 UTC
As an enhancement suggestion for the next versions, I think that multipath-tools
could benefit from more manageability options; "-l" for displaying what is
happening is already good, but I think commandline interfaces to the other
multipath features would be good:

multipath --switch-group <multipath device identifier> <group identifier>
for example would switch the multipath device identified (either by it's name or
by one of it's components, like -l already accepts) to the group identified
(either by number or by one of it's components).

--(enable|disable)-group, --(fail|reinstate)-path would work in similar manners,
and --(queue|fail)_if_no_path would send the appropriate message.

Also an option to affect all groups at once (to enable them all again, for
example) for all or a selected device would be helpful.

multipath(d) already uses some of these messages internally, and it'd be good
for useability of they were exported, so that users don't have to construct the
dmsetup message command themselves.

Comment 1 Christophe Varoqui 2005-04-22 22:25:19 UTC
I don't really follow you on this : the current design forces the admin to setup
a config file suited to its env, then forget about it. Why would it want to care
about direct map manipulations, that multipathd will reverse at the first occasion.

As an example, force a fail_path on a valid path and you'll see it instantly
reinstateed. Force a switch_pg to a pg with a lower weight, and you'll see a
switch back to the highest prio pg.

I think this is sane.

Not to say an admin is not allowed to reap off the daemon to mess with maps, but
it this case I don't see why multipath-tools would have to give assistance ...
dmsetup is the right tool for that.

Comment 2 Lars Marowsky-Bree 2005-04-25 12:11:34 UTC
I disagree partially. 

Ok, failing the paths might not be the best example, but switching PGs (or
temporarily disabling one) does have it's merits.

Use case 1: The admin wants to temporarily move load from one overloaded switch
to another one. Of course, if that one fails, it should switchback to the other,
because slow service is better than none - so disabling the switch ports isn't a
good idea.

Use case 2: Consider 2 nodes; one of them loses access to parts of the fabric
and switches over. The other node constantly switches back. The ping-pong effect
is going to cause problems. Of course, the real fix is to fix the first node,
but the immediate workaround is to tell the second node to switch PGs.

The option to set/disable the queue path option for testing is also useful.

Sure, these are non-persistent and will be reset the next time the daemon is
restarted and reloads its configuration file; that's just fine; having a
volatile and non-volatile configuration is pretty standard.

To summarize my position: I agree that the goal is to have the admin setup the
configfile once, or even better, not require any configuration at all but just
do the right thing out of the box. This is a great goal for user-friendliness
and indeed very sane.

However, almost every piece of logic should have an easily accessible admin
override to cater to situations where the automated logic doesn't do the right
thing. (And there's a substantial chance these will be high stress situations
where things don't work as planned; exactly NOT the situation in which you'd
want the admin to start learning dmsetup manually, or having support staff
dictate the commands over the phone...)

I think this too is part of being user-friendly.

Comment 3 John Poelstra 2008-07-08 03:41:17 UTC

I'm assuming several versions have been released since the "next version"
mentioned in comment #1.  Is this bug still relevant?


Comment 4 Alasdair Kergon 2011-02-11 20:29:44 UTC
Ben, how much of this, if any, do you think we still need?

Comment 5 Ben Marzinski 2011-02-14 21:42:36 UTC
We already have equivalents to all the commands initially mentioned.

Note You need to log in before you can comment on or make changes to this bug.