Re: [PATCH v2 11/20] libmultipath: don't try to set up failed wwids again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux