Red Hat Bugzilla – Bug 155550
multipath -l rescans all paths
Last modified: 2007-11-30 17:11:04 EST
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.
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)
- 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 ?
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
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
So I think your proposal makes perfect sense.
Oh, actually: The path checker & prio status could be requested from the daemon
(if running), no?
'-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.
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.