Re: Make LUNs higher than 255 more friendly to look at

[Brian Bunker <brian@purestorage.com>]

I am not suggesting changing the the LUN value itself, only to print it in a way that make more sense with
what the user would expect. I am open to sharpening the check if you are worried about LUN addressing
different than peripheral and flat, but I think that this is arguably better than what shows without it.

Here is an example, the user has connected LUNs up to 256. I am including just LUNs 255 and 256 to
show what I mean:

root@c106-18-ct0:~# purevol connect target1 --host init106-18 --lun 255
Name     Host Group  Host        LUN
target1  -                     init106-18  255
root@c106-18-ct0:~# purevol connect validation1 --host init106-18 --lun 256
Name         Host Group  Host        LUN
validation1  -                   init106-18  256

What does multipath -ll show?

[root@init106-18 multipath-tools-0.8.3]# multipath -ll
3624a9370385e6cda676493f900011014 dm-0 PURE,FlashArray
size=500G features='0' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 6:0:0:255   sdd 8:48  active ready running
  |- 7:0:0:255   sdg 8:96  active ready running
  |- 8:0:0:255   sdb 8:16  active ready running
  `- 9:0:0:255   sdc 8:32  active ready running
3624a9370385e6cda676493f900011013 dm-1 PURE,FlashArray
size=500G features='0' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 6:0:0:16640 sde 8:64  active ready running
  |- 7:0:0:16640 sdh 8:112 active ready running
  |- 8:0:0:16640 sdi 8:128 active ready running
  `- 9:0:0:16640 sdj 8:144 active ready running

So what you can see is that it is already confusing to the user. The first 255 LUNs are in peripheral
addressing mode but when you get to LUN 256 then it moves into flat address space. What I expect the
user would expect if they didn’t understand the shift would be 255 and 256.

My change makes this into:
[root@init106-18 multipath-tools-0.8.3]# multipath -ll
3624a9370385e6cda676493f900011014 dm-0 PURE,FlashArray
size=500G features='0' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 6:0:0:255 sdd 8:48  active ready running
  |- 7:0:0:255 sdg 8:96  active ready running
  |- 8:0:0:255 sdb 8:16  active ready running
  `- 9:0:0:255 sdc 8:32  active ready running
3624a9370385e6cda676493f900011013 dm-1 PURE,FlashArray
size=500G features='0' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 6:0:0:256 sde 8:64  active ready running
  |- 7:0:0:256 sdh 8:112 active ready running
  |- 8:0:0:256 sdi 8:128 active ready running
  `- 9:0:0:256 sdj 8:144 active ready running

Thanks,
Brian

Brian Bunker
SW Eng
brian@purestorage.com



> On Sep 25, 2020, at 7:14 AM, Steffen Maier <maier@linux.ibm.com> wrote:
> 
> 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@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


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