On Tue, 2021-09-28 at 12:42 -0500, Benjamin Marzinski wrote: > On Tue, Sep 28, 2021 at 03:16:08PM +0000, Martin Wilck wrote: > > On Tue, 2021-09-28 at 09:42 -0500, David Teigland wrote: > > > > > > I have pondered this quite a bit, but I can't say I have a concrete > > plan. > > > > To avoid depending on "udev settle", multipathd needs to partially > > revert to udev-independent device detection. At least during > > initial > > startup, we may encounter multipath maps with members that don't > > exist > > in the udev db, and we need to deal with this situation gracefully. > > We > > currently don't, and it's a tough problem to solve cleanly. Not > > relying > > on udev opens up a Pandora's box wrt WWID determination, for > > example. > > Any such change would without doubt carry a large risk of > > regressions > > in some scenarios, which we wouldn't want to happen in our large > > customer's data centers. > > I'm not actually sure that it's as bad as all that. We just may need > a > way for multipathd to detect if the coldplug has happened. I'm sure > if > we say we need it to remove the udev settle, we can get some method > to > check this. Perhaps there is one already, that I don't know about. Our ideas are not so far apart, but this is the wrong thread on the wrong mailing list :-) Adding dm-devel. My thinking is: if during startup multipathd encounters existing maps with member devices missing in udev, it can test the existence of the devices in sysfs, and if the devices are present there, it shouldn't flush the maps. This should probably be a general principle, not only during startup or "boot" (wondering if it makes sense to try and add a concept like "started during boot" to multipathd - I'd rather try to keep it generic). Anyway, however you put it, that means that we'd deviate at least to some extent from the current "always rely on udev" principle. That's what I meant. Perhaps I exaggerated the difficulties. Anyway, details need to be worked out, and I expect some rough edges. > > I also looked into Lennart's "storage daemon" concept where > > multipathd > > would continue running over the initramfs/rootfs switch, but that > > would > > be yet another step with even higher risk. > > This is the "set argv[0][0] = '@' to disble initramfs daemon killing" > concept, right? We still have the problem where the udev database > gets > cleared, so if we ever need to look at that while processing the > coldplug events, we'll have problems. If multipathd had started during initrd processing, it would have seen the uevents for the member devices. There are no "remove" events, so multipathd might not even notice that the devices are gone. But libudev queries on the devices could fail between pivot and coldplug, which is perhaps even nastier... Also, a daemon running like this would live in a separate, detached mount namespace. It couldn't just reread its configuration file or the wwids file; it would have no access to the ordinary root FS. > > > > > 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. 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. > > I admit that a wwid being in the wwids file doesn't mean that it is > definitely a multipath path device (it could always still be > blacklisted > for instance). Also, the ability to move the wwids file is > unfortunate, > and probably never used. But it is the case that every wwid in the > wwids > file has had a multipath device successfully created for it. This is > true regardless of the find_multipaths setting, and seems to me to be > a > good hint. Conversely, if a device wwid isn't in the wwids file, then > it > very likely has never been multipathed before (assuming that the > wwids > file is on a writable filesystem). Hm. I hear you, but I am able to run "multipath -a" and add a wwid to the file without it being created. Actually I'm able to add bogus wwids to the file in this way. Regards, Martin > _______________________________________________ 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/
