[dm-devel] Fwd: different LUN numbers under the same dm device

[Brian Bunker]

> 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 at suse.de			      +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 at purestorage.com
> 
> 
> 

Brian Bunker
brian at purestorage.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20120611/767734e8/attachment.htm>