<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.<div><br></div><div>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.<br><div><br></div><div>Thanks,</div><div>Brian</div><div><br><div><div>On May 15, 2014, at 2:09 PM, Christophe Varoqui <<a href="mailto:christophe.varoqui@opensvc.com">christophe.varoqui@opensvc.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi,<div><br></div><div>you could also try to extend your observation to the timing of the udev triggers.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best regards,</div><div>Christophe Varoqui</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 10:40 PM, Stewart, Sean <span dir="ltr"><<a href="mailto:Sean.Stewart@netapp.com" target="_blank">Sean.Stewart@netapp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-05-15 at 10:23 -0700, Brian Bunker wrote:<br>
> I will get both the page 0x83 and page 0x80 data of the path when the problem happens. In our case the page 0x83 and page 0x80 data are the same always. The page 0x83 data has the additional encoding and OUI information but the bytes after that 3624a9370 are exactly the same. I am wondering about how the path gets its wwid when it comes back.<br>

<br>
</div>This is through the call to /lib/udev/scsi_id, which pulls it from page<br>
0x83.  The function that does it is called get_uid().  It calls the<br>
external program, then strips trailing whitespace, replacing spaces with<br>
null characters.  You could try simply making the log message in that<br>
function a level 2 instead of a 3, so we'll know that get_uid completed<br>
for the path, and what it found for the uid.<br>
<div class=""><br>
><br>
> In our case we have a controller coming back online after doing something. All the LUNs are re-discovered by the initiator and an sd device gets created for each LUN path which came back. The serial of the sd device at that time I believe is known to the initiator. The multipathd gets that sd device and comes up with a wwid. I would expect that wwid would be just the serial number plus some bytes in the beginning but that is not what we see in the fail case. The path wwid and path serial are pointing to different volumes on the array. I expect that the sd device will show the same data for page 0x83 and page 0x80 pointing to the same volume on the array but I will verify that with more logging.<br>

><br>
</div>Similar to what I said above, you could change the log message in<br>
scsi_ioctl_pathinfo (after the get_serial call) from level 3 to level 2.<br>
<br>
Beyond that, I don't have many more ideas here..  Another wild guess, I<br>
suppose it's possible that the data from the 0x83 inquiry at the time of<br>
discovery could be incomplete?  Then, when you run the command later,<br>
manually, after it comes up, it appears just fine. I don't think I see<br>
the code zeroing the memory for the wwid in the newly allocated path<br>
struct before it tries to populate the buffer, but that seems kind of<br>
farfetched.<br>
<div class=""><br>
> You can see from my previous posts on this issue. (They go back for some time). That the page 0x83 and page 0x80 from sg3_utils show that they point to same LUN but different from the dm device that they are coalesced under.<br>

><br>
> Thanks,<br>
> Brian<br>
<br>
</div>Hope this helps.<br>
<br>
Thanks,<br>
Sean<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
dm-devel mailing list<br>
<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/dm-devel" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
</div></div></blockquote></div><br></div>
--<br>dm-devel mailing list<br><a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>https://www.redhat.com/mailman/listinfo/dm-devel</blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div>Brian Bunker</div><div><a href="mailto:brian@purestorage.com">brian@purestorage.com</a></div><div><br></div></span><br class="Apple-interchange-newline">

</div>
<br></div></div></body></html>