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

[Mike Christie <michaelc cs wisc edu>]

On 06/08/2012 01:59 AM, Hannes Reinecke wrote:
> (Third mail on this topic .. I really should've read the entire
> thread before answering. But there you go.)
> 
> On 06/08/2012 01:26 AM, Brian Bunker wrote:
>> The answer is yes they did have that LUN NAA value that comes from page code 0x83 in inquiry.
>> Then the LUN was unmasked from that initiator. That initiator is
> holding on to those device
>> names in multipath. If you query them when they are in the state
> that I show in the
>> multipath -ll result, they will not return an NAA number at all in
> page code 0x83 or
>> a serial number in page code 0x80. They will instead return a PQ
> of 1 meaning that the
>> LUN is capable of supporting a peripheral device but is not currently.
>>
> Hehe.
> 
>> I understand about LUN's needing different NAA numbers and ours do, and we also have
>> different LUN serial numbers for each LUN on the target. An
> initiator doesn't always
>> have to access to all LUN's that it once did. It is the re-use of
> dm devices that
>> seems to cause this result.
>>
> No, rather a problem with the SCSI stack. multipath normally relies
> on udev to keep track of any device events, like LUNs coming and
> going. But this only works reliably if these events are triggered
> via the underlying transport, like FC RSCN et al.
> 
> 'Real' scsi events which will get transmitted via Sense codes are
> not evaluated further, sadly.
> 
> So short-term you are supposed to call 'rescan-scsi-bus.sh -r'
> whenever you made any LUN assigment changes on the array.
> Mid-term we already agreed on implementing some proper sense code
> handling in the SCSI midlayer.
> However, as usual in these cases, real life interfered and I've been
> busy with other things.
> But it's definitely on the agenda.
> 

I think this is a bug in multipath though. Even though we are not
handling sense that would indicate the path/device is not longer valid
(PQ changed values) if it was sent, it would make sense that when
multipath is assembling devices it would not create a device with
different NAA/UUID values. So multipath should not make a device that
includes sde, sdd, sdar and sdba but where sde and sdd have a different
UUID than sdar and sdba, right?

Brian, what is the device returning in this case for sde and sdd? Does
it return a error, or is it returning invalid data thinking the OS would
check the PQ value first? If it returns a error what is the sense, asc
and ascq?