On Mon, 2007-06-18 at 15:56 +0200, Heiko Carstens wrote: > One of my current disks has an FCP LUN of 0x401040ba00000000... That's just That's correct and coped with ... SCSI LUNs are BE ... this is still only a four byte lun ... it actually says Flat Space addressing, 2 level LUN: 16-168 > the limit that scsilun_to_int() (four bytes that is) still works with. > Just wondering if there are patches around that make the SCSI stack work > with eight byte LUNs? We've been around this several times, but no-one's ever seen a LUN that goes beyond 2 levels (and our current scheme correctly copes with all 2 level LUNs)... to go beyond 2 level, it's a simple case of converting the LUN to u64 and updating the accessors, but we still haven't found a reason to do it yet. > Otherwise this looks like replacing a broken approach with a different but > at least incomplete approach. The above LUN would be translated to a SCSI > stack internal LUN of 1085947920. Hmm... The only broken bit about our approach is the fact that we print the translated value (as you show) which doesn't correspond to the actual hierarchy. We could quietly update to use the correct number, but we'd probably have to change our device ID. For only single level LUs, it's easy, we still use H:C:I:L for flat space, I could see something like H:C:I:L4-L3-L2-L1 Or we could just combine them into a single enumerated LUN. For peripheral Encoding, perhaps something like: H:C:I:B4,L4-B3,L3-B2,L2-B1,L1 Logical Unit addressing is starting to look really horrible: something like: H:C:I:T4,B4,L4-T3,B3,L3... And obviously, there's no translation for the extended address method. James - 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
