Bug 155550 - multipath -l rescans all paths
multipath -l rescans all paths
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-21 08:09 EDT by Lars Marowsky-Bree
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-05 17:37:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lars Marowsky-Bree 2005-04-21 08:09:37 EDT
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 18:34:45 EDT
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 08:17:45 EDT
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 08:18:26 EDT
Oh, actually: The path checker & prio status could be requested from the daemon
(if running), no?
Comment 4 Christophe Varoqui 2005-05-04 17:12:16 EDT
'-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 17:41:31 EDT
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.