Olaf Hering wrote:
> Upcoming IBM pSeries firmware can boot from iscsi. To configure the
> openfirmware boot-device string, we need to construct a correct
> devicepath. This path includes the lun. Its currently not 100% clear
> how exactly this lun value has to look like.
>
> sg_luns may be the tool to get the value. But its current output is not
> parseable by scripts. It even gives the same output for two different
> scsi devices:
>
> girgendwas:~ # lsscsi
> [0:0:0:0] disk DGC RAID 5 0219 /dev/sda
> [0:0:0:1] disk DGC RAID 5 0219 /dev/sdb
> [0:0:0:2] disk DGC RAID 5 0219 /dev/sdc
> [0:0:0:3] disk DGC RAID 5 0219 /dev/sdd
> girgendwas:~ # sg_luns -V
> sg_luns: version: 1.05 20060127
> girgendwas:~ # sg_luns /dev/sdd
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
> 0000000000000000
> 0001000000000000
> 0002000000000000
> 0003000000000000
> girgendwas:~ # sg_luns /dev/sdc
> Lun list length = 32 which imples 4 lun entries
> Report luns [select_report=0]:
> 0000000000000000
> 0001000000000000
> 0002000000000000
> 0003000000000000
>
> Is it possible to print the lun only for the requested scsi device?
Olaf,
sg_luns is an application client driving the SCSI
REPORT LUNS command. It is a "trick" SCSI command
since even though it addresses a logical unit, it
is really the target that replies (as it is the target
that knows about the sibling logical units) ***.
The REPORT LUNS response gives no indication which
(if any) 64 bit lun was addressed.
Now I would not want to break the link between sg_luns
and the SCSI REPORT LUNS command. Adding an extra
parameter to try and find the lun associated with the
file descriptor has a few problems (from my point
of view):
- it would be OS specific (sg_luns isn't currently)
- within Linux there are different mechanisms in
the 2.4 and 2.6 series kernels.
In your example above a combination of lsscsi and sg_luns
gives the answer ("0003000000000000") but lsscsi is
linux 2.6 series specific. sg_scan would probably work
as a replacement for lsscsi (and sg_scan also works in the
lk 2.4 series (and Windows)).
To address the parsability of sg_luns output, I recently
added a '--quiet' option to suppress the extraneous
output.
In summary sg_luns is probably not what you want!
What about the lu _name_? For iSCSI the lu should
yield a world wide unique "SCSI name" designator
in the device identification VPD page (see SPC-4
and SAM-4 Annex A; the iSCSI standard woffles in
this area).
*** a better way to get a target to report its active
luns is to use the REPORT LUNS well known logical
unit but hardly anyone implements that.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
