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@xxxxxxxxxxxxxxx [mailto:stgt-owner@xxxxxxxxxxxxxxx] On Behalf Of Braun, David Sent: Thursday, November 29, 2012 8:41 AM To: ronnie sahlberg Cc: stgt@xxxxxxxxxxxxxxx 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@xxxxxxxxx] Sent: Wednesday, November 28, 2012 11:34 PM To: Braun, David Cc: stgt@xxxxxxxxxxxxxxx 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@xxxxxxx> 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
