[stgt] Why LUN0?

[Braun, David]

I took a (quick) look at RFC-3720 and RFC-5048. 5048 states that "the
SCSI REPORT LUNS command requests a target SCSI layer" to provide an
inventory of LUNs. This tells me that the REPORT LUNS command really is
LUN-less (the value in the LUN field of the CDB is ignored). I don't
have copies of the SCSI specs to verify this.

If my interpretation is correct then TGTD needs to process these
LUN-less requests at the target level without descending into its LUN
command processing code. (forgive me if my terminology is incorrect -
feel free to correct)

BTW - my feeble memory recalls watching SCSI bus controllers (the
hardware type) polling for devices on start-up (via BIOS extensions?).
With the hardware type controllers this took some time but wasn't huge
and only needed to be done once (I have no experience with removable
LUNs if such exist).

Dave 

-----Original Message-----
From: stgt-owner at vger.kernel.org [mailto:stgt-owner at vger.kernel.org] On
Behalf Of Braun, David
Sent: Thursday, November 29, 2012 8:41 AM
To: ronnie sahlberg
Cc: stgt at vger.kernel.org
Subject: RE: Why LUN0?

I took a quick look at the code (not the RFC) and it I don't see
anything special about LUN0 being the only LUN that can respond to
REPORT_LUNS. Any LUN would work (assuming scsi_cmd_perform(...) is where
all the action is). Wouldn't this mean that one would have to ensure to
create at least a LUN0 (assuming the REPORT_LUNS isn't a LUN-less
command (I'm SCSI-ignorant)). My suspicion is that the REPORT_LUNS
command is a LUN-less command and would be responded to by the bus
controller in the non-internet implementation of SCSI.

Off to peruse the RFC.

Dave

-----Original Message-----
From: ronnie sahlberg [mailto:ronniesahlberg at gmail.com]
Sent: Wednesday, November 28, 2012 11:34 PM
To: Braun, David
Cc: stgt at vger.kernel.org
Subject: Re: Why LUN0?

REPORTLUNS needs this. You must present a LUN 0 that can respond to
REPORTLUNS so that an initiator can discover which LUNs are available.

I think this is part of SAM for SCSI-3.


Without a LUN:0   your initiator might either not be able to access
any LUNs at all on your target,
or if you are lucky/unlucky (I dont really know which,  both options are
highly undesireable)  it might fall back to old style discovery and spin
for many many minutes in a "try to talk to each LUN from LUN 0 to LUN
<huge number> one at a time to see which ones exist"
everytime you reboot and the host needs to re-scan the bus.



regards
ronnie sahlberg

On Wed, Nov 28, 2012 at 5:53 PM, Braun, David <David.Braun at drs.com>
wrote:
> I'm trying to understand the need for LUN0. Is this required by the 
> iSCSI standard (RFC-3720) or is it an artifact of the implementation?
> As a test I modified a copy of tgtd and tgtadm to allow the "-force"
> argument to the logicalunit delete function and it seems to work. BUT 
> I must confess I'm ignorant of what the ramifications could be. Could 
> someone explain the need for LUN0 or why I shouldn't be too surprised 
> when this hack blows up in my face?
>
> Thanks
>
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in the

> body of a message to majordomo at vger.kernel.org More majordomo info at

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