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
