* 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).