REPORT LUNS mandatory SPC-3?

Matthew Jacob mjacob at
Sun Jul 28 15:40:36 PDT 2002

* From the T10 Reflector (t10 at, posted by:
* Matthew Jacob <mjacob at>

I'm afraid I don't find argument #i persuasive. A device that supports luns
should be able to say, trivially, that it supports only lun 0. Or is it
implicit for, say, device type X that device type X can only support lun 0?

I also am afraid I believe that #ii is implementation driving architecture.

It becomes a question as to where you want to put discriminating logic. Do you
want to require all OSs that will use REPORT LUNS to have to parse possibly
incomplete data out of INQUIRY data in order to decide whether to issue REPORT

I couldn't agree more that there are a large number of devices where luns
other than 0 aren't very meaningful. But that measure of meaningulness has a
lifetime considerably less than the specification in question. Devices that
you are working with today may for some reason tomorrow have LUNs tomorrow,
and then we'll be in the same mess we're in for SCSI-3 devices living in a
SCSI-2 world where we gingerly are probing past lun 7 to find which of 16384
luns for level 0 addressing might be there.

I could see your point if you factor in the hybrid device as something being
very cost sensitive (i.e., you need to squeeze gates/logic *so* much that you
want to trim as much as possible). That said, I'd rather have a starting
position either requiring REPORT LUNS or having unambiguous information in
INQUIRY data that the device in question cannot support more than LUN 0 rather
than farming the REPORT LUNS command out to various specific device types.
SCSI has suffered terribly since 1983 or so from just such an approach.



On Sun, 28 Jul 2002, Peter Johansson wrote:

> * From the T10 Reflector (t10 at, posted by:
> * Peter Johansson <PJohansson at>
> *
> At 02:01 PM 7/28/2002 -0700, Matthew Jacob wrote:
> >Can you say more why you believe REPORT LUNS is inappropriately placed in 
> >SPC-3?
> i) Why should a device that implements only LU zero be required to support 
> ii) In the SBP-3 working group, we are discussing hybrid devices whose 
> medium may be accessible either by consumer electronics command sets (such 
> as AV/C, developed by the 1394 Trade Association) or by SCSI commands (such 
> as RBC or SBC). So far, we think the simplest way to make medium usually 
> under the control of AV/C available for access by RBC commands is to 
> temporarily instantiate a LU with an RBC device type and access restricted 
> to the relevant portion of the medium. The usefulness of this scheme might 
> be defeated if we were required to report these ephemeral LUNs via REPORT 
> LUNS, since the initiator's operating system might claim exclusive control 
> ahead of the application that desired access to the medium.
> I hope that argument i) is sufficiently persuasive on its own; I've 
> provided ii) only as an additional example as to why REPORT LUNS is not 
> necessarily useful or desired in all environments.
> Regards,
> Peter Johansson
> Congruent Software, Inc.
> 98 Colorado Avenue
> Berkeley, CA  94707
> (510) 527-3926
> (510) 527-3856 FAX
> PJohansson at
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list