On Fri, 2018-04-13 at 11:12 -0500, Benjamin Marzinski wrote: > On Fri, Apr 13, 2018 at 12:19:12AM +0200, Martin Wilck wrote: > > On Thu, 2018-04-12 at 13:46 -0500, Benjamin Marzinski wrote: > > > On Wed, Apr 04, 2018 at 06:16:25PM +0200, Martin Wilck wrote: > > > > With "find_multipaths smart", we accept paths as valid if they > > > > are > > > > already part of a multipath map. This patch avoids doing a full > > > > path > > > > and device-mapper map scan for this case, speeding up > > > > "multipath > > > > -u" > > > > considerably. > > > > > > I feel like this supports my idea from 17/20. I really think that > > > in > > > smart mode, the only time we should be claiming a device as > > > multipath > > > is > > > on an add event, if it has always been claimed (or pretend > > > claimed) > > > as a > > > multipath path, or if it is currently a multipath path. Once we > > > have > > > let > > > a uevent go by for a path without setting SYSTEMD_READY=0, > > > anything > > > else > > > is free to use it, and we simply can't safely set > > > SYSTEMD_READY=0, > > > unless we know that multipathd has already grabbed the device. > > > > We have to remember that in the udev db then. That doesn't work for > > coldplug aside, but we agree that's not an issue. By checking a > > suitable udev variable, we can make sure that we never set > > SYSTEMD_READY=0 after having released the device to the system. > > We can safely set SYSTEMD_READY=0 if we know that the device is now > part > of an existing multipath device, but yeah. Patch set v5 will implement this logic. I'm currently testing it. I simply look at DM_MULTIPATH_DEVICE_PATH as saved in the udev db. Regards Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
