On Fri, Oct 04, 2019 at 07:03:26AM +0000, Martin Wilck wrote: > Hi Xose, hi Ben, > > On Thu, 2019-10-03 at 16:44 -0500, Benjamin Marzinski wrote: > > On Thu, Oct 03, 2019 at 08:28:06PM +0200, Xose Vazquez Perez wrote: > > > > Redhat doesn't include the udev rules file that sets ID_SCSI_VPD, so > > there are some rare cases where this property blacklists valid > > devices. > > Thus, it's easier for us to simply include this property line in the > > default multipath.conf, and let users remove it if necessary. I would > > be > > fine with this being included upstream, but I suspect it would mess > > with > > other ditsros which are currently assuming that it is there. > > Hm. ID_SCSI_VPD is nowhere referenced in the upstream code. The default > is "(SCSI_IDENT_|ID_WWN)", where SCSI_IDENT_ could be regarded as a > SUSE-ism because the SCSI_IDENT_* properties are set by sg_inq / sg_vpd > calls, and I'm not sure if other distros consequently use sg_inq rather > than scs_id like we do. We (SUSE) have been working on replacing > scsi_id by sg3_utils calls in upstream systemd, but so far that hasn't > been merged, systemd maintainers are very cautious about touching these > udev rules. Sorry, I meant SCSI_IDENT_. The properties blacklist line originally was (ID_SCSI_VPD|ID_WWN). I never bothered to update the commit message when I changed this commit to deal with the new line. > > I'd be interested in seeing an example for a device that is erroneously > excluded by the default blacklist rule. I'm not sure if there are any specific arrays that always fail to set ID_WWN. I've gotten rare reports about this failing, but after I tell them to not use that property blacklist line, they go away, and I never get enough information to figure out what specifically is happening that means that ID_WWN isn't getting set. It's something that I've been meaning to look into, but with this patch, there's not much urgency around it. > > I posted this upstream and Hannes NAKed it a while back. We still > > find > > it useful, since the default multipath.conf file for Redhat sets > > find_multipaths to yes. You can currently avoid the race that this is > > fixing by setting find_multipaths to smart, but there were objections > > to > > using that as a default in Redhat. However, I never really understood > > the objection to this patch, and I'd be fine with re-posting it. > > https://www.redhat.com/archives/dm-devel/2014-July/msg00011.html > > I'm with Hannes. Doing this in dracut, udev rules, or systemd service > files seems cleaner to me than yet another daemon that tries to > interpret the kernel command line. > > See e.g. how we implemented multipath=off (cd3184e). Yep. But again, this is already solveable now by running multipath with find_multipaths=smart, so I'm not sure that there's a need for it upstream at all. If I rework this patch to something that would be accpetable upstream, I'll post it, in case anyone is interested in it. -Ben -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
