Purpose of REPORT LUNS well known logical unit?
Edward A. Gardner
eag at ophidian.com
Tue Jan 27 13:32:25 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
*
I've been looking into how / when an initiator can expect to use REPORT
LUNS. A detailed history of REPORT LUNS appears at the end of this
message. It can be summarized as:
SPC defined REPORT LUNS, but gave no guidance as to when it should be
implemented.
SPC-2 requiredthat REPORT LUNS be implemented for LUN 0 if the target
supported any other LUN.
SPC-3 requires that REPORT LUNS be implemented for LUN 0 regardless of
other LUNs.
SPC-3 also defines the REPORT LUNS well known logical unit, but it is optional.
Why would an initiator ever access the REPORT LUNS well known logical
unit? The initiator is better off issuing a REPORT LUNS to LUN 0. If the
REPORT LUNS well known logical unit is present, then REPORT LUNS is
implemented at LUN 0, but the converse is not true.
Is something missing, either in SPC-3 or my reading of it? If there is
some purpose for the REPORT LUNS well known logical unit that is different
|from REPORT LUNS on LUN 0, then we need some words in SPC-3 explaining that
purpose. Otherwise, with the status quo the REPORT LUNS well known logical
unit seems to only create confusion, we would be better off eliminating it.
Note that if we had had well known logical units first, we would have
defined REPORT LUNS with them and avoided the LUN 0 requirement. It is the
fact that the LUN 0 requirements already exist that makes the REPORT LUNS
well known logical unit seem pointless.
History of REPORT LUNS
REPORT LUNS first appears in SPC-r08 (20-Sep-95) as an optional
command. Nothing is said about when it shall / should be supported by a
target. The CDB, data format and overall description are essentially the
same as today except for the less precise wording that was common at the
time. The only significant difference is that spc-r08 specifies that an
ILLEGAL REQUEST sense key be returned if the Allocation length is shorter
than 16 bytes (this length needed to return one LUN).
The final version of SPC (SPC-r11a, 28-Mar-97) has added a statement that
REPORT LUNS shall not be affected by reservations or persistent
reservations. There are some additional minor wording changes with no
significant effect.
SPC2r01 (13-Nov-97):
Adds the HiSupport bit to standard INQUIRY data.
States that REPORT LUNS shall be supported when HiSupport is one.
States that REPORT LUNS should be supported on LUN zero if the device is
capable of supporting a LUN other than zero.
SPC2r06 (15-Nov-98) removes the statement that REPORT LUNS shall not be
affected by reservations or persistent reservations, since that information
is moved to a table in the reservations section.
SPC2r10 (19-May-99) substantially changes much of the wording:
The logical unit inventory that shall be returned is specified in terms of
the PERIPHERAL QUALIFIER value.
A SCSI device that is capable of supporting a LUN address other than zero
shall support REPORT LUNS on logical unit zero.
Improves / corrects the wording for short Allocation lengths.
States that REPORT LUNS shall be processed even when a unit attention is
pending, and introduces the notion of an unit attention due to a change in
logical unit inventory.
States that the LUN report should be available without media access delays.
SPC2r11 (24-Jul-99) corrects a shall to a should is the discussion of
allocation length, and adds a note that SPC devices may return ILLEGAL
REQUEST if allocation length is less than 16.
The final version of SPC-2 (SPC2r20, 18-Jul-01) contains a trivial wording
change, but is otherwise identical to SPC2r11.
SPC3r01 (22-Sep-01):
Adds words to formalize that the list of accessible LUNs may vary by
initiator or target port.
Adds the SELECT REPORT field to control whether well=known LUNs are reported.
Adds the Well Known Logical Units clause and the REPORT LUNS well known
logical unit.
SPC3r07 (3-May-02) contains a minor editorial change.
SPC3r08 (25-Jul-02) makes REPORT LUNS mandatory for LUN 0. However, there
was an error incorporating this from 02-260r1 which was not fixed until
SPC3r17.
SPC3r13 (16-May-03) minor editorial changes.
SPC3r17 (??-Jan-04) correct mis-incorporation of 02-260r1.
Edward A. Gardner eag at ophidian dot com
Ophidian Designs 719 593-8866 voice
1262 Hofstead Terrace 719 210-7200 cell
Colorado Springs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list