[dm-devel] [PATCH v4 18/20] multipath -u: quick check if path is multipathed

[Martin Wilck]

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 at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)