[dm-devel] an interesting note on LUN coalescing

[Stewart, Sean]

On Thu, 2014-05-15 at 17:40 -0700, Brian Bunker wrote:
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.

Sounds good.  I'm curious about why this is happening, too.

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.

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.

Thanks,
Brian

On May 15, 2014, at 2:09 PM, Christophe Varoqui <christophe.varoqui at opensvc.com<mailto:christophe.varoqui at opensvc.com>> wrote:

Hi,


you could also try to extend your observation to the timing of the udev triggers.


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.


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.


Best regards,
Christophe Varoqui

Thanks,
Sean Stewart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20140516/97f98df8/attachment.htm>