<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>Hannes, We send a LIP for really only one reason that we can't get around any other way yet. We have a LUN 0 device that is a non data LUN. When you zone an initiator to our target, it logs in and interrogates LUN 0. That is before we have any data LUN's assigned to that initiator. When we assign data LUN's to that initiator, there is no way to notify that initiator via the target that something has changed and the initiator should again do a REPORT_LUNS. I know that if we had a data LUN that the initiator was already seeing we could use a unit attention and sense data for this, but since our LUN 0 is not a device, the initiator does not send I/O to it beyond its initial login. A rescan that includes a LIP is our only way of re logging into the target from the initiator. A rescan of existing LUN's would not work in the case of assigning LUN's for the first time down a path of initiator that is currently logged into the target or one where the rports have been removed because of a timeout leaving only the LUN 0 again. Brian On Jun 10, 2012, at 11:38 PM, Hannes Reinecke wrote: <blockquote type="cite">On 06/08/2012 07:18 PM, Brian Bunker wrote: </blockquote><blockquote type="cite"><blockquote type="cite">Mike and all, </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks for the information. I think that everyone is on the same page now. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The problem comes up for us because we have mostly automated tools </blockquote></blockquote><blockquote type="cite">processing </blockquote><blockquote type="cite"><blockquote type="cite">this output and they choked when they saw 4 paths even though as </blockquote></blockquote><blockquote type="cite">Hannes </blockquote><blockquote type="cite"><blockquote type="cite">pointed out 2 are faulty. We changed the automated scripts to look </blockquote></blockquote><blockquote type="cite">at the </blockquote><blockquote type="cite"><blockquote type="cite">state as well so we will get past this. We were mostly curious why </blockquote></blockquote><blockquote type="cite">we only </blockquote><blockquote type="cite"><blockquote type="cite">see this occasionally and on some dm devices. I will also change the </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">rescanning mechanism to use 'rescan-scsi-bus.sh'. I think that we </blockquote></blockquote><blockquote type="cite">should </blockquote><blockquote type="cite"><blockquote type="cite">use both -r and -i right so that we send a LIP to the FC target? </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite">Gnaa. I should have never implemented the '-i' option in the first </blockquote><blockquote type="cite">place. '-i' is just a horrible hack for misbehaving SANs. </blockquote><blockquote type="cite">FC arrays should detect any change in the port mapping themselves, </blockquote><blockquote type="cite">either via RSCNs or if a LIP reset occured. </blockquote><blockquote type="cite">During normal operation LIP should _not_ be necessary; in fact, I </blockquote><blockquote type="cite">would consider it a bug if you do. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite"><blockquote type="cite">I think that our current rescan behavior was just to go the </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/sys/class/fc_host/hostX and echo 1 to issue_lip. To answer all the </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">questions, yes LUN 10 and LUN 12 did point to the same data LUN on the </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">array not two different ones. If we ever shared NAA numbers for </blockquote></blockquote><blockquote type="cite">different </blockquote><blockquote type="cite"><blockquote type="cite">LUN's on the array itself we would have a big problem and would see </blockquote></blockquote><blockquote type="cite"><blockquote type="cite">corruption everywhere. </blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> </blockquote></blockquote><blockquote type="cite">Close, but not banana. 'issue_lip' is in fact a nasty method of </blockquote><blockquote type="cite">invoking a scan, it basically amounts to a card reset. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">The 'correct' way would be to do a </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">echo '- - -' > /sys/class/fc_host/hostX/scan </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">and then remove all devices for which sg_tur / sg_inq returns an </blockquote><blockquote type="cite">error code. </blockquote><blockquote type="cite">Which is what rescan-scsi-bus.sh -r does. </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">But occasionally you're indeed better off by coding it by hand. </blockquote><blockquote type="cite">I know rescan-scsi-bus.sh far too well to recommend it to each and </blockquote><blockquote type="cite">sundry :-) </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Cheers, </blockquote><blockquote type="cite"> </blockquote><blockquote type="cite">Hannes </blockquote><blockquote type="cite">-- </blockquote><blockquote type="cite">Dr. Hannes Reinecke zSeries & Storage </blockquote><blockquote type="cite"><a href="mailto:hare@suse.de">hare@suse.de</a> +49 911 74053 688 </blockquote><blockquote type="cite">SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg </blockquote><blockquote type="cite">GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) </blockquote> Brian Bunker <a href="mailto:brian@purestorage.com">brian@purestorage.com</a> </div></blockquote></div> <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; font-size: medium; "><div>Brian Bunker</div><div><a href="mailto:brian@purestorage.com">brian@purestorage.com</a></div><div> </div> </div> </body></html>