Re: different LUN numbers under the same dm device

[Hannes Reinecke <hare@suse.de>]

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@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)