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