[stgt] Why LUN0?

[Boaz Harrosh]

Ye Ye ...

But why does this LUN0 of yours must be a do nothing, good
for no one LUN? Why can't it not just be a real LUN with
real function?

Like on any other HW or SW target in the world except
the tgtd freak.

We want to be proud of our work?

Cheers
Boaz

On 12/10/2012 05:59 PM, ronnie sahlberg wrote:
> How is this a problem?
> 
> Scsi Architectural Model specifies there has to be a LUN zero.
> 
>   SAM 4.6.14.1
>   The logical unit is the class to which commands are sent. One of the
> logical units within the SCSI target device
>   shall be accessed using the LUN zero or the REPORT LUNS well known
> logical unit number.
> 
> 
> So it does look like STGT does implement the standard correctly.
> 
> 
> regards
> ronnie sahlberg
> 
> On Mon, Dec 10, 2012 at 7:50 AM, Boaz Harrosh <bharrosh at panasas.com> wrote:
>> 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