[stgt] [PATCH 15/15] Remove dummy RAID controller from LUN 0

[Boaz Harrosh]

On 11/26/2009 01:07 PM, FUJITA Tomonori wrote:
> On Thu, 26 Nov 2009 12:27:37 +0200
> Boaz Harrosh <bharrosh at panasas.com> wrote:
> 
>> On 11/26/2009 12:22 PM, FUJITA Tomonori wrote:
>>> On Thu, 26 Nov 2009 12:08:21 +0200
>>> Boaz Harrosh <bharrosh at panasas.com> wrote:
>>>
>>>> On 11/26/2009 10:13 AM, FUJITA Tomonori wrote:
>>>>> On Wed, 25 Nov 2009 17:42:04 +0200
>>>>> Boaz Harrosh <bharrosh at panasas.com> wrote:
>>>
>>>> Lets try and find an acceptable solution. What if we refuse any
>>>> connections until we have the first LUN configured. I know how to do
>>>> it in iscsi, is there a way to do it in a general way?
>>>
>>> OpenSolaris target implementation requests you to create a target
>>> *with* a logical unit. It's another hacky solution.
>>>
>>> I don't think that we need to change the current way.
>>
>> What about a command line option for us users who would like not
>> to see that tgt-LUN0. Would you accept a command line switch, off
>> by default. Something like --hide-lun0 ?
> 
> What I'm against is hacky code for shadow or hidden lun. I prefer to
> keep the code clean rather than handle poor OSes kindly.

I don't care about poor OSes, I care about Linux initiator. When I have
multi-lun osd-target environment that extra target adds an
sg + request_queue + all that extra resources that are un-needed, never
used on the initiator machine. And it is surprising and raises questions
as one logged into an osd-target and gets this extra device in the logs.
I suspect that it is the same for any target that exports a specialized
device. (I'm not using any scsi-disks so I can't comment on that)

Is there a better way to get rid of it then the "hacky hidden lun"? maybe
an error handling code at the core that eliminates the need for it? what is
your suggestion?

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