[dm-devel] Make LUNs higher than 255 more friendly to look at

[Steffen Maier]

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 at purestorage.com>
> ___
> --- 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