Hi Brian,
On 9/24/20 11:10 PM, 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.
Signed-off-by: Brian Bunker <brian@xxxxxxxxxxxxxxx>
___
--- a/libmultipath/print.c 2020-09-24 13:52:18.661828011 -0600
+++ b/libmultipath/print.c 2020-09-24 14:28:27.603542303 -0600
@@ -394,7 +394,7 @@
pp->sg_id.host_no,
pp->sg_id.channel,
pp->sg_id.scsi_id,
- pp->sg_id.lun);
+ (pp->sg_id.lun & 0x4000) ? pp->sg_id.lun - 0x4000 : pp->sg_id.lun);
}
static int
For Linux SCSI devices, and if I understood the code correctly
[libmultipath/discovery.c:scsi_sysfs_pathinfo()], this seems the SCSI LUN value
being part of the SCSI device name in its H:C:T:L format. AFAIK, Linux
intentionally treats this as an opaque 64-bit value to reflect a T10 SAM LUN
[as decimal number with reversed LUN levels, though, so a peripheral addressing
LUN happens to look like a small integer value]. This way, it always works with
any (current or future) LUN format and its potentially different LUN format
fields/parts.
Users may use the hcil output to find the corresponding Linux SCSI device by
its name. Would this still work if the output value was modified?
Also, some (FCP-attached SCSI) storages in particular cases use LUN format
fields in addition to "... LUN" to code a larger somewhat opaque 64-bit T10 SAM
LUN value. For instance "BUS IDENTIFIER" with peripheral addressing, or a
non-zero 2nd level with flat space addressing. Above conversion seems to at
least result in unexpected values.
((Not sure for this case, as NVMe might use its own print output code in
libmultipath/foreign/nvme.c: nvme_sysfs_pathinfo() seems to be another user
assigning a non-zero value to sg_id.lun [originating in the nsid
(namespace-ID?)]. An unconditional value conversion in the output printing code
path based on SCSI knowledge might break output of values belonging to NVMe
paths.))
--
Mit freundlichen Gruessen / Kind regards
Steffen Maier
Linux on IBM Z Development
https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
