[dm-devel] [PATCH 09/31] libmultipath: support MPATH_UDEV_NO_PATHS_FLAG on map creation

[Martin Wilck]

On Wed, 2017-09-13 at 15:33 -0500, Benjamin Marzinski wrote:
> On Sun, Sep 03, 2017 at 12:38:38AM +0200, Martin Wilck wrote:
> > Some vendor kernels (e.g. SUSE) have supported loading multipath
> > maps without valid paths for a long time. Without that feature,
> > problems can occur in failover scenarios when multipathd tries
> > to (re)load maps after device failure/removal, because multipathd's
> > attempts to reload the configuration may fail unnecessarily.
> > The discussion in the kernel community is ongoing
> > (see e.g. https://patchwork.kernel.org/patch/4579551/).
> 
> I don't object to the patch itself, but I'm pretty sure that this
> solution to multipath's reloading issues is not currently under
> consideration upstream.  It got Naked, and I wrote and alternative
> method, which got accepted
> 
> https://www.redhat.com/archives/dm-devel/2014-September/msg00094.html
> 
> Do you still need this patch? 

This is a hard question to answer. We've been using Hannes' approach in
SLES for years with no problems, and it's hard to predict whether or
not dropping it would cause regressions. Hannes is more qualified than
myself to comment on the kernel side details.


> The solution that's currently upstream
> doesn't allow you to load new devices with failed paths, but it
> avoids
> the issues that caused the SUSE patch to get Nak'ed. The multipath
> user-space code already won't allow you to create a multipath device
> if
> it can't open the path device, so I don't see why you need the
> ability
> for the kernel to allow creation of devices with only failed paths. I
> admit, there is a small window where multipath could open the path
> device, and then the path device could fail before the load is sent
> to
> the kernel.  In this case, with your patch, you could still create
> the
> device (I believe).  But the much more likely case, where the path
> has
> failed before multipath tries to open it, is still there. I don't see
> the benefit of adding code to fix the corner case, while the common
> case
> still doesn't work. Is there some other case where your patch is
> helpful
> that I'm missing?
> 
> At any rate. Even if that kernel patch doesn't go upstream, I have no
> objection to changing the code so the udev rules are robust enough to
> handle this situation.
> 
> ACK

Thanks a lot.

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)