<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="GENERATOR" content="GtkHTML/4.6.5"> </head> <body> On Thu, 2014-05-15 at 17:40 -0700, Brian Bunker wrote: <blockquote type="CITE">What I am going to do is this. I will do a page 0x83 EVPD page inquiry before entering the find_mp_by_wwid function. I will strncmp the NAA number from page 0x83 with the wwid. If I find a difference, I will log it. I expect that if I just step on the wwid with the NAA number that I get from page 0x83 that I get if the two are different then my problem will go away, but it would be interesting to see how the difference happens. I will update with my findings once it fires again. </blockquote> <blockquote type="CITE"> </blockquote> Sounds good. I'm curious about why this is happening, too. <blockquote type="CITE"> </blockquote> <blockquote type="CITE">Just as an aside, why not just use the NAA page 0x83 number instead of the callout to scsi_id? The inquiry plumbing is all there already in discovery to get the serial number and with a small addition could return the NAA value as a string to match the wwid expectation. </blockquote> <blockquote type="CITE"> </blockquote> Like Christophe said, newer versions of the multipath-tools code use information from udev, instead. I assume the executable was there to make it more user-configurable. Some device types use the --page=0x80 flag to scsi_id, and I see a couple of device types in hwtable that use a different executable for getuid callout, altogether. <blockquote type="CITE"> </blockquote> <blockquote type="CITE">Thanks, </blockquote> <blockquote type="CITE">Brian </blockquote> <blockquote type="CITE"> </blockquote> <blockquote type="CITE">On May 15, 2014, at 2:09 PM, Christophe Varoqui <<a href="mailto:christophe.varoqui@opensvc.com">christophe.varoqui@opensvc.com</a>> wrote: </blockquote> <blockquote type="CITE"> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">Hi, </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE"> </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">you could also try to extend your observation to the timing of the udev triggers. </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE"> </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">You did not describe the scenario leading to this misbehaviour, but if it involves paths remove-readd it's critical udev completed the /dev/ entries janitoring ... unless multipathd might exec scsi_id on the wrong devices. </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE"> </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">Latest distro versions implement a strict serialization, using the udevd socket, thanks to Hannes work. You might try to reproduce the problem with those to get a broader viewpoint, but it sure won't help with your supporting your products on older distros. </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE"> </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">Best regards, </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE">Christophe Varoqui </blockquote> </blockquote> <blockquote type="CITE"> <blockquote type="CITE"> </blockquote> </blockquote> Thanks, Sean Stewart </body> </html>