On Mon, 2018-03-26 at 13:47 -0500, Benjamin Marzinski wrote: > On Mon, Mar 19, 2018 at 04:01:46PM +0100, Martin Wilck wrote: > > Once setting up a map has failed, don't try to set it up again. > > This applies to "multipathd reconfigure" and even multipathd > > restart, > > too. That's deliberate - if a WWID is marked as failed, we don't > > wont > > to bother with it again, unless the admin explicitly tells us so. > > Specifically, the exceptions are: > > > > 1) multipathd add map $MAP > > 2) multipathd add path $PATH > > 3) multipath $PATH > > > > In these cases, addmap() will eventually be called again, and the > > failed > > flag will be set according to it's return status. Unless the reason > > for > > the previous failure has been fixed, it may well be "failed" again. > > > > Inofficially, it's also possible to manually remove a failed marker > > under > > /dev/shm/multipath/failed_wwids and run "multipathd reconfigure". > > The code looks fine, but I wonder why this is necessary. You already > posted patches that let multipathd issue uevent to claim a path > device > after if it was not previously claimed. I admit that you don't > generally > see multipathd succeed in creating a device after failing to, but > it's > easy to imagine situations where it could. For instance, if a path > device appears and then disappears soon after, multipathd would fail > to > create the device because when the path device finally reappeared for > good. > > I see that this will keep multipathd from needlessly retrying in-use > devices whenever a path comes or goes, but I don't know of any harm > that > has ever caused, and I can see this causing harm. Am I missing > something > here? Hm. You've got a point there. The only code path where the "failed" status _must_ really be honored is "multipath -u" (obviously, without that, the whole purpose of the patch set would be forfeited). I'll give it a try. 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
