Purpose of REPORT LUNS well known logical unit?

[Edward A. Gardner]

* 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