Dne 08. 06. 21 v 17:47 Martin Wilck napsal(a):
On Di, 2021-06-08 at 10:39 -0500, David Teigland wrote:
. Use both native md/mpath detection *and* udev info when it's
readily
available (don't wait for it), instead of limiting ourselves to one
source of info. If either source indicates an md/mpath component,
then we consider it true.
Hm. You can boot with "multipath=off" which udev would take into
account. What would you do in that case? Native mpath detection would
probably not figure it out.
multipath-tools itself follows the "try udev and fall back to native if
it fails" approach, which isn't always perfect, either.
A third related improvement that could follow is to add stronger
native
mpath detection, in which lvm uses uses /etc/multipath/wwids,
directly or
through a multipath library, to identify mpath components. This
would
supplement the existing sysfs and udev sources, and address the
difficult
case where the mpath device is not yet set up.
Please don't. Use libmpathvalid if you want to improve in this area.
That's what it was made for.
Problem is addition of another dependency here.
We may probably think about using 'dlopen' and if library is present use it,
but IMHO libmpathvalid should be integrated into libblkid in some way -
linking another library to many other projects that needs to detect MP devices
really complicates this a lot. libblkid should be able to decode this and
make things much cleaner.
I'd also vote for lvm2 plugin for blkid as forking thousands of process simply
always will take a lot of time (but this would require quite some code
shufling withing lvm codebase).
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/