[dm-devel] [PATCH] libmultipath: Extract the LUN number for peripheral, flat, and logical unit address methods
Hannes Reinecke
hare at suse.de
Wed Sep 30 12:08:13 UTC 2020
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 at 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
More information about the dm-devel
mailing list