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@xxxxxxx/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@xxxxxxx +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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
