[CAM] Widening lun_id_t to 64-bits

[Douglas Gilbert]

On 13-12-11 12:58 AM, Nathan Whitehorn wrote:
> On 12/10/13 17:57, Douglas Gilbert wrote:
>> On 13-12-11 12:41 AM, Douglas Gilbert wrote:
>>> On 13-12-10 10:09 PM, Nathan Whitehorn wrote:
>>>> Modern SCSI hardware often uses 64-bit logical units (LUNs). The patch found at
>>>> http://people.freebsd.org/~nwhitehorn/lun64.diff widens the type of lun_id_t to
>>>> 64 bits, bumps CAM_VERSION, and begins exposing these to drivers that are
>>>> marked
>>>> as supporting extended LUNs. No behavior is changed except that peripheral with
>>>> very long LUNs that didn't work before will start working. Binary compatibility
>>>> with old code is also kept. There is, however, a chance that some 3rd party
>>>> software might be unhappy about the type widening, so I'd appreciate any
>>>> testing
>>>> results. Barring any issues, I will commit this on Friday.
>>>
>>> Interesting, Hannes Reinecke is trying to do something
>>> very similar in the Linux SCSI subsystem. His patch set
>>> today will be the third attempt in a year (by my count)
>>> and he might just get over the top this time. There is
>>> some support in my sg3_utils package for the way Linux
>>> is implementing "64 bit LUNs". The sg3_utils package
>>> also supports FreeBSD so I'm interested in what your
>>> mapping will be.
>>>
>>> Now, as you are no doubt aware, SCSI (www.t10.org and specifically
>>> sam5r15.pdf) does not have 64 bit LUNs, it has 8 byte LUNs in
>>> SCSI order (i.e. big endian). Given that major architectures
>>> like i386 and x86_64 are little endian, the mapping between
>>> a 64 bit integer in native form and an 8 byte SCSI LUN is
>>> a bit of a puzzle. That becomes a little harder when you try
>>> for low numbered integers representing the T10 3 bit LUNs
>>> (showing my age), 8 bit LUNs and 16 bit LUNs.
>>>
>>> Down to brass tacks: what exactly will a SCSI REPORT LUNS
>>> WELL KNOWN LOGICAL UNIT number [T10 (in hex): c1 01 00 00
>>> 00 00 00 00] be in one of your 64 bits LUNs? Will that be
>>> the same in little endian and big endian architectures?
>>> There is also the representation of that LUN in logs; for
>>> example lun=13907397124296802304 is not very intuitive.
>>>
>>> More examples would be great, perhaps from the 4, 6 and 8 byte
>>> "extended logical unit addressing format".
>>>
>>>
>>> Robert Elliott who has been a T10 technical editor has written
>>> a paper on this subject but google fails me, perhaps someone
>>> else can supply the url. His advice was too late for Linux
>>> and perhaps it is already too late for FreeBSD.
>>
>> The document I was trying to find was a www.t10.org proposal:
>> 06-003r1, see its overview for a rationale. The Logical Unit
>> Representation Format section was accepted and can be found
>> in sam5r15.pdf section 4.7.2
>>
>> Doug Gilbert
>>
>>
>
> Ah, OK. That we are following.
> -Nathan

BTW A T10 troublemaker tried to extend 8 byte LUNs to something
longer in order to hold a proposed conglomerate LUN format.
He did succeed in getting conglomerate LUN format in but not
extending LUNs beyond 8 bytes. However he did get a 65th bit in,
sort of. See the new LU_CONG bit in a standard INQUIRY
response (spc4r36n.pdf).

Doug Gilbert