[stgt] Why LUN0?

[Boaz Harrosh]

I think, last I tried, (that was 5 years ago), that tgtd was crashing.
But please try again, lots of things changed since then.

Cheers
Boaz

On 12/10/2012 06:06 PM, Braun, David wrote:
> I do believe you! I think. I'm mostly trying to understand.
> 
> And thank you for the clarification - I thought it was an implementation choice but wanted to be sure.
> 
> My --force patch (I'll submit it if you want) didn't exist until a few weeks ago.
> 
> Let me ask this. What bad things will happen if there are no LUNs? The response is well structured so a 0 need not break the protocol. And is correct at the time. The Client will just have to ask again sometime later.
> 
> Dave
> 
> -----Original Message-----
> From: Boaz Harrosh [mailto:bharrosh at panasas.com] 
> Sent: Monday, December 10, 2012 10:51 AM
> To: Braun, David
> Cc: ronnie sahlberg; stgt at vger.kernel.org
> Subject: Re: Why LUN0?
> 
> I wish you would believe me. It all works as long as you have "at least" one LUN, of any kind. But if there are no LUNs it will not work. It is not an STD problem it is an implementation problem.
> 
> Now since from the time U tgtdadm a new target, to the time U tgtadm a LUN for that new target there is a window of time that the target is LUN-less and if any communication creeps into that time window, bad things will happen.
> 
> So the current solution is to have a do-nothing-LUN0 for every target created, and tgtdadm from LUN1 and up.
> 
> My Patch avoids the do-nothing-LUN0, and waits for the first tgtadm to create a LUN0. Though with my patch there is still the above problem unless you can guaranty no connections activity within the LUN-less time window, which I have on my systems.
> 
> Your --force LUN0 is a very good solution. And should be very stable. I did not know it exists. In any way once you have your
> LUN0 up, every thing will be running fine and standard compliant for sure.
> 
> Cheers
> Boaz
> 
> On 11/29/2012 04:27 PM, Braun, David wrote:
>> 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
>>
> 

--
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