Re: [PATCH] libmultipath: Extract the LUN number for peripheral, flat, and logical unit address methods

[Hannes Reinecke <hare@suse.de>]

On 9/30/20 1:09 PM, Steffen Maier wrote:
> On 9/29/20 1:14 AM, Brian Bunker wrote:
>> For LUNs between 0 and 255 peripheral addressing is used. For LUNs 
>> higher than 255 the LUN addressing
>> should switch to flat according to the specification. Instead of 
>> printing out the LUN number without regard to
>> the shifting of address method, display the LUN as it was intended to 
>> be the user connecting the LUN. The
>> current display leaves a non-obvious 16384 offset.
>>
>> In short, a LUN connected as 258 will show up in multipath output as 
>> 16642. Instead display it as the
>> expected 258. This is for display only and doesn’t change the actual 
>> contents of the LUN variable.
> 
> [this is kind of a continuation of the discussion that started with the 
> 1st version of the path in 
> https://www.redhat.com/archives/dm-devel/2020-September/msg00592.html]
> 
> Users and tools such as 
> https://github.com/ibm-s390-tools/s390-tools/blob/master/ziomon/ziomon 
> parse the hcil output of multipath(d) to find the corresponding Linux 
> SCSI device by its well-defined name.
> I think this change would break those.
> 
> IIRC, tools such as rescan-scsi-bus.sh [sg3_utils] were intentionally 
> changed from decoding the LUN format to working with an opaque 64-bit LUN.
> [https://lore.kernel.org/linux-scsi/51288C5F.1080802@suse.de/T/#maba954fc50efa24e4c0544506d4c4025269d6c60] 
> 
I can not agree more.
The principal problem is that there was a shift in the definition of the 
LUN number between SCSI-3/SAM and SAM-2; prior to SAM-2 _any_ 64-bit 
number was a valid LUN, whereas SAM-2 introduced the LUN number structure.
So any meaning a LUN might have depends on the claimed standard.
Additionally, quite some arrays operate in 'legacy' mode, trying to 
preserve backwards compability with the original SCSI-2 standard.
Hence figuring out which standard is actually used by the implementation 
is challenging at times.

But it also means that LUN 0x4100 could refer to LUN 16640 (for SCSI-3), 
or to LUN 256 (for SAM-2).
Or the device might choose to use hierarchical LUN addressing, which 
makes it pretty hard to extract a valid (and unique!) LUN number.

So in the end we decided to _not_ decode the LUN number, as the internal 
structure is only ever useful for the target, not the initiator.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel