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 155550 - multipath -l rescans all paths
Summary: multipath -l rescans all paths
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-21 12:09 UTC by Lars Marowsky-Bree
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-05 21:37:47 UTC


Attachments (Terms of Use)

Description Lars Marowsky-Bree 2005-04-21 12:09:37 UTC
multipath -l rescans all physical paths; which, if a path is failing/timed out
can take quite long and gets stuck easily.

I think it would be better if it just scanned the DM multipath tables and
reported what it finds there, w/o accessing the backing devices. This would also
be much, much faster.

Comment 1 Christophe Varoqui 2005-04-22 22:34:45 UTC
I could make a "light list" option, but not rescaning all paths will trim the
output from :
- prio (not printed now actually)
- path state (according to checkers)
- h/b/t/l
- devname (/dev/sda)

Now, path_discovery() have this new flag to fetch just what is necessary.
I personnaly think the bare minimum info to output in addition to DM table and
status are h/b/t/l and devname.

I could make that the output of '-l', '-ll' adding checkers, '-lll' adding prio

What do you think ?

Comment 2 Lars Marowsky-Bree 2005-04-25 12:17:45 UTC
Well, scanning the devname doesn't require to actually _open_ the device nodes
though (and thus doesn't cause IO delays); merely stat()ing them is enough, or
even scanning /proc/partitions for the name associated with the major:minor.

h/b/t/l likewise only requires to scan sysfs, w/o needing to access the physical
device.

And, when I'm asking for the current status, I want the kernel's view, not what
the path checker thinks ;-) (The path checker could be displayed as additional
information.)

So I think your proposal makes perfect sense.


Comment 3 Lars Marowsky-Bree 2005-04-25 12:18:26 UTC
Oh, actually: The path checker & prio status could be requested from the daemon
(if running), no?

Comment 4 Christophe Varoqui 2005-05-04 21:12:16 UTC
'-l', '-ll', as described above is merged in commit
b30da450994dc52b3db45b5268a6fb418094796b at korg.

I suggest closing this one, as prio values are only relevant as a debug info and
is available via '-v3+'. I think '-lll' is not required after all.

Comment 5 Alasdair Kergon 2005-05-05 21:41:31 UTC
Closed: using 'NEXTRELEASE' to indicate that it's resolved in multipath-tools
and will get included in Fedora next time we import your tarball.

It's still possible to continue the discussion here after it's closed, and it
can easily be re-opened if we do decide we want more changes.


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