On Monday 25 June 2007 16:03, Hannes Reinecke wrote:
> 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@xxxxxxxxxxxx> 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
What do you mean with "like we had it" ?
I thought you were quite happy with the new version making
the old manual counting thing ("zfcp-ism") obsolete.
What's the benefit of adding another (LUN) attribute to the midlayer, I don't get
what this is supposed to solve.
The initial question was, should we not display the long-ish LUN value in
hex format making it easier for admins (and us) to actually use it
as it is.
I think Luben and Stefan suggested a good way to do that, ok apart from the be64 bits :-)
So, just use the struct scsi_lun in its full extend, for the sysfs without a leading "0x",
and forgetting about the scsilun_to_int conversion which isn't good for anything.
This way we would be conform to SAM4 as well even though I'm getting the impression
that this isn't the major goal of this discussion.
Anyway, before anyone else is suggesting some other magic attribute extension to the LUN value,
why not leave it as it is and just have it serving this one purpose of being a unique number ?
(yeah, yeah I know there's already some meaning behind the 4 levels)
Just my 2 cents !
Cheers Swen
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
