Re: lsscsi and sg3_utils betas for testing 64 bit LUNs

2013-03-06 Thread Douglas Gilbert

On 13-03-06 10:10 AM, Douglas Gilbert wrote:

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


Last second edits; the invocation line should be 'lsscsi -g'


[0:0:0:0]diskATA  INTEL SSDSC2CW12 400i  /dev/sda   /dev/sg0
[7:0:0:1]diskLinuxscsi_debug   0004  /dev/sdb   /dev/sg1
[7:0:0:49409]wlunLinuxscsi_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:


[0:0:0:0x]  diskATA  INTEL SSDSC2CW12 400i  /dev/sda
[7:0:0:0x0001]  diskLinuxscsi_debug   0004  /dev/sdb
[7:0:0:0xc101]  wlunLinuxscsi_debug   0004  -

# lsscsi -xx
[0:0:0:0x]  diskATA  INTEL SSDSC2CW12 400i  /dev/sda
[7:0:0:0x0001]  diskLinuxscsi_debug   0004  /dev/sdb
[7:0:0:0xc101]  wlunLinuxscsi_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
   >>Second level addressing:
 Peripheral device addressing: bus_id=4, target=170
   >>Third level addressing:
 Peripheral device addressing: bus_id=1, target=187
   >>Fourth level addressing:
 Peripheral device addressing: lun=255

# sg_luns --test=020304aa01bb00ff -H
Decoded LUN:
   Peripheral device addressing: bus_id=0x02, target=0x03
   >>Second level addressing:
 Peripheral device addressing: bus_id=0x04, target=0xaa
   >>Third level addressing:
 Peripheral device addressing: bus_id=0x01, target=0xbb
   >>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 .


# sg_luns --test=020304aa01bb00ffL -H
Linux 'word flipped' integer LUN representation: 0xff01bb04aa0203
Decoded LUN:
   Peripheral device addressing: bus_id=0x02, target=0x03
   >>Second level addressing:
 Peripheral device addressing: bus_id=0x04, target=0xaa
   >>Third level addressing:
 Peripheral device addressing: bus_id=0x01, target=0xbb
   >>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.



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


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


lsscsi and sg3_utils betas for testing 64 bit LUNs

2013-03-06 Thread 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_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]diskATA  INTEL SSDSC2CW12 400i  /dev/sda   /dev/sg0
[7:0:0:1]diskLinuxscsi_debug   0004  /dev/sdb   /dev/sg1
[7:0:0:49409]wlunLinuxscsi_debug   0004  -  /dev/sg2

# lsscsi -g --lunhex
[0:0:0:0x]  diskATA  INTEL SSDSC2CW12 400i  /dev/sda
[7:0:0:0x0001]  diskLinuxscsi_debug   0004  /dev/sdb
[7:0:0:0xc101]  wlunLinuxscsi_debug   0004  -

# lsscsi -xx
[0:0:0:0x]  diskATA  INTEL SSDSC2CW12 400i  /dev/sda
[7:0:0:0x0001]  diskLinuxscsi_debug   0004  /dev/sdb
[7:0:0:0xc101]  wlunLinuxscsi_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
  >>Second level addressing:
Peripheral device addressing: bus_id=4, target=170
  >>Third level addressing:
Peripheral device addressing: bus_id=1, target=187
  >>Fourth level addressing:
Peripheral device addressing: lun=255

# sg_luns --test=020304aa01bb00ff -H
Decoded LUN:
  Peripheral device addressing: bus_id=0x02, target=0x03
  >>Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaa
  >>Third level addressing:
Peripheral device addressing: bus_id=0x01, target=0xbb
  >>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
  >>Second level addressing:
Peripheral device addressing: bus_id=0x04, target=0xaa
  >>Third level addressing:
Peripheral device addressing: bus_id=0x01, target=0xbb
  >>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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html