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: 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)
Brian Bunker brian@xxxxxxxxxxxxxxx
|
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
