* Make LUNs higher than 255 more friendly to look at
@ 2020-09-24 21:10 Brian Bunker
2020-09-25 14:14 ` Steffen Maier
2020-09-26 4:23 ` Bart Van Assche
0 siblings, 2 replies; 4+ messages in thread
From: Brian Bunker @ 2020-09-24 21:10 UTC (permalink / raw)
To: device-mapper development
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
Brian Bunker
SW Eng
brian@purestorage.com
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Make LUNs higher than 255 more friendly to look at 2020-09-24 21:10 Make LUNs higher than 255 more friendly to look at Brian Bunker @ 2020-09-25 14:14 ` Steffen Maier 2020-09-25 16:10 ` Brian Bunker 2020-09-26 4:23 ` Bart Van Assche 1 sibling, 1 reply; 4+ messages in thread From: Steffen Maier @ 2020-09-25 14:14 UTC (permalink / raw) To: Brian Bunker, device-mapper development 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Make LUNs higher than 255 more friendly to look at 2020-09-25 14:14 ` Steffen Maier @ 2020-09-25 16:10 ` Brian Bunker 0 siblings, 0 replies; 4+ messages in thread From: Brian Bunker @ 2020-09-25 16:10 UTC (permalink / raw) To: Steffen Maier; +Cc: device-mapper development 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Make LUNs higher than 255 more friendly to look at 2020-09-24 21:10 Make LUNs higher than 255 more friendly to look at Brian Bunker 2020-09-25 14:14 ` Steffen Maier @ 2020-09-26 4:23 ` Bart Van Assche 1 sibling, 0 replies; 4+ messages in thread From: Bart Van Assche @ 2020-09-26 4:23 UTC (permalink / raw) To: Brian Bunker, device-mapper development On 2020-09-24 14:10, 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); > } Please introduce a function for converting the LUN number format and add appropriate comments. An example is available here: https://github.com/bvanassche/scst/blob/adfc65513915176d9d85a9e9c734d0b298a66991/scst/src/scst_lib.c#L12117 Thanks, Bart. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-26 4:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-24 21:10 Make LUNs higher than 255 more friendly to look at Brian Bunker 2020-09-25 14:14 ` Steffen Maier 2020-09-25 16:10 ` Brian Bunker 2020-09-26 4:23 ` Bart Van Assche
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).