[Stgt-devel] [PATCH] Move device type to LUN
Hannes Reinecke
hare
Tue Jun 12 14:44:03 CEST 2007
FUJITA Tomonori wrote:
> From: Hannes Reinecke <hare at suse.de>
> Subject: Re: [Stgt-devel] [PATCH] Move device type to LUN
> Date: Mon, 11 Jun 2007 17:15:19 +0200
>
>> Pete Wyckoff wrote:
>>> hare at suse.de wrote on Tue, 05 Jun 2007 15:38 +0200:
>>>> This patch moves the device type down to the LUN structure.
>>>> And in doing so we now also have the proper peripheral device
>>>> type and peripheral device qualifier attributes for the INQUIRY
>>>> data.
>>> Makes sense to me too.
>>>
>>>> One thing puzzles me, though: do we support commands with no
>>>> LUN attached to it? IE is it valid to have 'cmd->dev == NULL'?
>>>> If so: where is the point here? If that's our handling of a
>>>> non-existing LUN 0 we should rather add a proper LUN 0 and
>>>> treat cmd->dev == NULL as an error case ...
>>> In the SCSI model, every device must have at least one LUN for
>>> handling REPORT LUNS and a couple other commands. It is addressed
>>> as LUN 0 or using the "well-known" LUN for the command. In the stgt
>>> abstraction, though, there is no magic LUN like this. Instead
>>> things like spc_inqury use cmd->dev == NULL to handle this case.
>>>
>> Ah. Hence.
>>
>>> Perhaps it is reasonable to create a special device for these
>>> commands. Up in target.c, you could assign cmd->dev to target->dev,
>>> where that is the special device, paralleling the way that
>>> target->cmd_queue is used. As a side effect, lots of "if (cmd->dev)
>>> ... else ILLEGAL_REQUEST" clauses can be removed from device code
>>> too.
>>>
>> Well, I actually thought of creating a proper LUN 0 with type 0xc.
>
> We still need to handle cmd->dev == NULL case though probably we can
> remove cmd->dev == NULL case in device type code.
>
> I don't have storage systems that work in your way. Is it common?
>
>
Yes, quite common. HP and EMC (to name but a few) do it this way.
Most storage arrays actually refuse to attach any devices to LUN0, as
this is a pure management LUN.
I will draft up a patch which creates a proper controller LUN0.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare at suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Markus Rex, HRB 16746 (AG N?rnberg)
More information about the stgt
mailing list