From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 11 00:15:49 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BED3A91; Wed, 11 Dec 2013 00:15:49 +0000 (UTC) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id C3DDE1E52; Wed, 11 Dec 2013 00:15:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id B6A7D2041AF; Wed, 11 Dec 2013 01:15:47 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfYLsp6jtK1n; Wed, 11 Dec 2013 01:15:45 +0100 (CET) Received: from [10.0.0.132] (142.87.202.84.customer.cdi.no [84.202.87.142]) by smtp.infotech.no (Postfix) with ESMTPA id B1170204079; Wed, 11 Dec 2013 01:15:45 +0100 (CET) Message-ID: <52A7AEAE.1030307@interlog.com> Date: Wed, 11 Dec 2013 01:15:42 +0100 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Nathan Whitehorn , FreeBSD SCSI Subject: Re: [CAM] Widening lun_id_t to 64-bits References: <52A7830B.2090803@freebsd.org> <52A7A69E.3030703@interlog.com> <52A7AA76.3060208@interlog.com> <52A7AAA3.5050404@freebsd.org> In-Reply-To: <52A7AAA3.5050404@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hannes Reinecke X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:15:49 -0000 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