Re: [PATCH RESEND 0/4] multipath-tools: fixes for path wwid detection and path change uevents

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

 



On Fri, 2018-10-05 at 18:07 -0500,  Benjamin Marzinski  wrote:
> On Tue, Oct 02, 2018 at 11:02:50PM +0200, Martin Wilck wrote:
> > Hi Ben, Christophe,
> > 
> > I found a problem with this old patch series of mine.
> > 
> > while I am still pondering about your latest series, it occured to
> > me
> > that my patch "get_uid: don't quit prematurely without udev" is
> > against
> > the spirit of your "retrigger uevents to try and get the uid
> > through
> > udev" patch from 2016 (688aa22b).
> > 
> > "get_uid: don't quit prematurely without udev" has been merged a
> > while
> > ago (08d42ee6). Should it be reverted??
> > 
> > Pro: the patch is against the "udev first" philosophy and subverts
> > the
> > retrigger logic.
> > Con: with the patch, we'll be able to retrieve WWIDs more quickly
> > in
> > some situations, as we don't have to wait for udev.
> > 
> > Either way (but more likely with my patch), it may happen that we
> > retrieve a WWID from sysfs or elsewhere first, and from udev later.
> > These WWIDs may not necessarily match, and a "WWID changed" problem
> > may
> > occur.
> > 
> > Please tell me what you think.
> 
> I'm having a hard time seeing how get_uid() could get called on a
> path
> without a udev device attached in multipathd. It can happen because
> of
> update_paths() in multipath, for paths that don't get discovered when
> searching for paths, but do belong to an existing multipath device. I
> don't think you patch will hurt anything here. So, unless I'm missing
> some code path in multipathd, I don't see a problem with this patch.

OK, fine then. Thanks for clarifying this.

> In fact, we should probably make scsi_uid_fallback() skip (or at
> least
> always pass) the retrigger check if we aren't in the daemon, so we
> always try the failback when we run multipath.

AFAICS that's already the case, because multipath sets 
conf->retrigger_tries = 0 on startup.

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




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

  Powered by Linux