On 06/08/2012 07:18 PM, Brian Bunker wrote: > Mike and all, > > Thanks for the information. I think that everyone is on the same page now. > The problem comes up for us because we have mostly automated tools processing > this output and they choked when they saw 4 paths even though as Hannes > pointed out 2 are faulty. We changed the automated scripts to look at the > state as well so we will get past this. We were mostly curious why we only > see this occasionally and on some dm devices. I will also change the > rescanning mechanism to use 'rescan-scsi-bus.sh'. I think that we should > use both -r and -i right so that we send a LIP to the FC target? > Gnaa. I should have never implemented the '-i' option in the first place. '-i' is just a horrible hack for misbehaving SANs. FC arrays should detect any change in the port mapping themselves, either via RSCNs or if a LIP reset occured. During normal operation LIP should _not_ be necessary; in fact, I would consider it a bug if you do. > I think that our current rescan behavior was just to go the > /sys/class/fc_host/hostX and echo 1 to issue_lip. To answer all the > questions, yes LUN 10 and LUN 12 did point to the same data LUN on the > array not two different ones. If we ever shared NAA numbers for different > LUN's on the array itself we would have a big problem and would see > corruption everywhere. > Close, but not banana. 'issue_lip' is in fact a nasty method of invoking a scan, it basically amounts to a card reset. The 'correct' way would be to do a echo '- - -' > /sys/class/fc_host/hostX/scan and then remove all devices for which sg_tur / sg_inq returns an error code. Which is what rescan-scsi-bus.sh -r does. But occasionally you're indeed better off by coding it by hand. I know rescan-scsi-bus.sh far too well to recommend it to each and sundry :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
