On Tue, Sep 28, 2021 at 03:16:08PM +0000, Martin Wilck wrote: > Hm. This would mean that the switch to event-based PV detection could > happen before "udev settle" ends. A coldplug storm of uevents could > create 1000s of PVs in a blink after event-based detection was enabled. > Wouldn't that resurrect the performance issues that you are trying to > fix with this patch set? Possibly, I'm unsure how this looks in practice, so I need to try it. When the device node exists will make a difference, not only when the uevent occurs. > > Otherwise, when the devices file is not used, > > md: from reading the md headers from the disk > > mpath: from reading sysfs links and /etc/multipath/wwids > > Ugh. Reading sysfs links means that you're indirectly depending on > udev, because udev creates those. It's *more* fragile than calling into > libudev directly, IMO. I meant /sys/dev/block/... (some of those files are links). We don't look at /dev symlinks created by udev. > Using /etc/multipath/wwids is plain wrong in > general. It works only on distros that use "find_multipaths strict", > like RHEL. Not to mention that the path can be customized in > multipath.conf. Right, it's not great and I held off for a couple years adding that. As a practical matter it can at least help. There's a constant stream of problems with mpath component detection, so anything that can help I'm interested in. I expect we could be more intelligent understanding multipath config to handle more cases. > multipathd does listen to uevents (only "udev" events, not "kernel"). > But that doesn't help us on startup. Currently we try hard to start up > after coldplug is finished. multipathd doesn't have a concurrency issue > like LVM2 (at least I hope so; it handles events with just two threads, > a producer and a consumer). The problem is rather that dm devices > survive the initramfs->rootfs switch, while member devices don't (see > above). The other day I suggested that multipath devices not be set up in the initramfs at all. If the root fs requires mpath, then handle that as a special one-off setup. Then the transition problems go away. But, I know basically nothing about this, so I won't be surprised if there are reasons it's done this way. Dave _______________________________________________ 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/
