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 -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
