Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer

[Hannes Reinecke <hare@suse.de>]

Swen Schillig wrote:
> On Friday 22 June 2007 16:11, James Bottomley wrote:
>> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
>>> James Bottomley <James.Bottomley@SteelEye.com> wrote:
>>>> A proposal to display the correct form of the LUN would be useful if you
>>>> wish to make it? ...  The problem is really that SAM specifies a
>>>> possible 4 level structure with 4 possible address methods per level.
>>>>
>>>> The well known LUNs should be simple; there are only three: Report Lun,
>>>> Access Controls and Target Log Pages.  The rest we really need input on.
>>>> For instance, I could see the vendors wishing us to combine a
>>>> multi-level flat addressing space into a single logical unit number,
>>>> whereas I could see them wanting us to supply some sort of hierarchy for
>>>> the peripheral and logical unit methods of addressing.
>>>>
>>>> Since you're already using 2 level flat addressing, how do you want to
>>>> see that represented?
>>> James, why would we would not want to display the lun per SAM4 4.6.2 as
>>> suggested by Stefan in a previous comment.
>> Because in a two LUN system, what was LUN 1 would then become LUN
>> 0x1000000000000 which looks a bit unpalatable.
>>
>> James
>>
>>
>> -
> 
> Despite the issue whether we should display and/or use (sysfs !?)
> full blown 64bit values, so with leading zeros, you still have the option to display, 
> for the single level addressing, the LUN as a 2 byte value as described in  SAM4 4.6.2. 
> So for your example this would be 0x0001 or 0x1, which is exactly what you'd like to see, right ?
> Only for 2+ level environment the 64bit representation comes into the play.
> 
> And, because you were asking how we'd like that to be represented, I personally prefer
> a full blown 64bit hex value with leading zeros.
> It makes the comparison to internal structures/models easier and gets us a bit closer
> to the documented (SAM4) standard.
> ...and I think we all can deal with a few extra digits being displayed.
> 
Well ...
why don't we stick with the original implementation like zfcp had it?
We can simpley expand the midlayer to add an attribute 'lun'
to each scsi_device. This would be the LUN as returned by eg
REPORT LUNS.
No translation, nothing. Would be easy to implement and would allow
any administrator to map the h:c:i:l value to the 'real' lun.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html