lsscsi and sg3_utils betas for testing 64 bit LUNs
To facilitate testing Linux 64 bit LUNs (the kernel holds only 32 bit LUNs internally at the moment), I have put up beta versions of lsscsi and the sg3_utils packages, see the top of this page: http://sg.danny.cz/sg/
lsscsi version 0.27 (beta 1) adds a --lunhex (-x) option, here is an example of its use:
# lsscsi -gs [0:0:0:0] disk ATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [7:0:0:1] disk Linux scsi_debug 0004 /dev/sdb /dev/sg1 [7:0:0:49409]wlun Linux scsi_debug 0004 - /dev/sg2
# lsscsi -g --lunhex [0:0:0:0x0000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] disk Linux scsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlun Linux scsi_debug 0004 -
# lsscsi -xx [0:0:0:0x0000000000000000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001000000000000] disk Linux scsi_debug 0004 /dev/sdb [7:0:0:0xc101000000000000] wlun Linux scsi_debug 0004 -
Additionally if sysfs offers a 64 bit (unsigned) integer in decimal for a LUN then this version will use it (previous lsscsi versions would have truncated the LUN to 32 bits).
In the sg3_utils beta the sg_luns utility is expanded to better handle T10 (SAM-5) LUNs and represent them in Linux 'word flipped' form if requested. sg_luns has an additional --test=LUNHEX option that can be used for decoding arbitrary T10 LUNs, for example:
# sg_luns --test=020304aa01bb00ff Decoded LUN: Peripheral device addressing: bus_id=2, target=3
Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=4, target=170
Quoted 1 line
Quoted 1 line
Third level addressing:
Peripheral device addressing: bus_id=1, target=187
Quoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=255
# sg_luns --test=020304aa01bb00ff -H Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03
Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaa
Quoted 1 line
Quoted 1 line
Third level addressing:
Peripheral device addressing: bus_id=0x01, target=0xbb
Quoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=0xff
# sg_luns --test=020304aa01bb00ffL -H Linux 'word flipped' integer LUN representation: 0xff01bb04aa0203 Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03
Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaa
Quoted 1 line
Quoted 1 line
Third level addressing:
Peripheral device addressing: bus_id=0x01, target=0xbb
Quoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=0xff
Now I'm hoping Hannes Reinecke will issue a new set of the "scsi: 64-bit LUN support" patches that address the issues that have been brought up. Then the real testing can begin.
Doug Gilbert
Quoted 9 lines · Douglas Gilbert
To facilitate testing Linux 64 bit LUNs (the kernel holds only 32 bit LUNs internally at the moment), I have put up beta versions of lsscsi and the
sg3_utilspackages, see the top of this page: http://sg.danny.cz/sg/lsscsi version 0.27 (beta 1) adds a --lunhex (-x) option, here is an example of its use:
# lsscsi -gs
Last second edits; the invocation line should be 'lsscsi -g'
Quoted 5 lines
[0:0:0:0] disk ATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [7:0:0:1] disk Linux scsi_debug 0004 /dev/sdb /dev/sg1 [7:0:0:49409]wlun Linux scsi_debug 0004 - /dev/sg2# lsscsi -g --lunhex
And the invocation here should be 'lsscsi --lunhex' What is happening is that redundant zeros to the right (according to the T10 LUN definition) of the LUN are dropped to lessen the clutter. When --lunhex is used twice (or -xx) then the whole 16 hex digits are output:
Quoted 32 lines
[0:0:0:0x0000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] disk Linux scsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlun Linux scsi_debug 0004 -# lsscsi -xx [0:0:0:0x0000000000000000] disk ATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001000000000000] disk Linux scsi_debug 0004 /dev/sdb [7:0:0:0xc101000000000000] wlun Linux scsi_debug 0004 -Additionally if sysfs offers a 64 bit (unsigned) integer in decimal for a LUN then this version will use it (previous lsscsi versions would have truncated the LUN to 32 bits).
In the
sg3_utilsbeta thesg_lunsutility is expanded to better handle T10 (SAM-5) LUNs and represent them in Linux 'word flipped' form if requested.sg_lunshas an additional --test=LUNHEX option that can be used for decoding arbitrary T10 LUNs, for example:# sg_luns --test=020304aa01bb00ff Decoded LUN: Peripheral device addressing: bus_id=2, target=3Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=4, target=170
Quoted 1 line
Quoted 1 line
Third level addressing:
Peripheral device addressing: bus_id=1, target=187
Quoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=255
# sg_luns --test=020304aa01bb00ff -H Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaaQuoted 1 line
Quoted 1 line
Third level addressing:
Peripheral device addressing: bus_id=0x01, target=0xbbQuoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=0xff
The trailing "L" on that hex number requests the Linux LUN representation. And if -H was given twice the Linux word flipped integer would be 0x00ff01bb04aa0203 .
Quoted 7 lines
# sg_luns --test=020304aa01bb00ffL -H Linux 'word flipped' integer LUN representation: 0xff01bb04aa0203 Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03Quoted 1 line
Quoted 1 line
Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaaQuoted 1 line
Quoted 1 line
Third level addressing:
Quoted 8 lines
Peripheral device addressing: bus_id=0x01, target=0xbbQuoted 1 line
Quoted 1 line
Fourth level addressing:
Peripheral device addressing: lun=0xffNow I'm hoping Hannes Reinecke will issue a new set of the "scsi: 64-bit LUN support" patches that address the issues that have been brought up. Then the real testing can begin.
And finally a question, if a target had a lot of LUNs then the sorting order will help finding one in a long list. So what sorting order should 64 bit LUNs have?
Doug Gilbert