From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 10 23:50:37 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 BED31487; Tue, 10 Dec 2013 23:50:37 +0000 (UTC) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7650F1CAE; Tue, 10 Dec 2013 23:50:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 6A3502041AF; Wed, 11 Dec 2013 00:41:24 +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 5wowa618CACn; Wed, 11 Dec 2013 00:41:22 +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 3FCA1204079; Wed, 11 Dec 2013 00:41:22 +0100 (CET) Message-ID: <52A7A69E.3030703@interlog.com> Date: Wed, 11 Dec 2013 00:41:18 +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-current@freebsd.org" , FreeBSD SCSI Subject: Re: [CAM] Widening lun_id_t to 64-bits References: <52A7830B.2090803@freebsd.org> In-Reply-To: <52A7830B.2090803@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: Tue, 10 Dec 2013 23:50:37 -0000 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. Doug Gilbert P.S. I know Linux has stupid typedefs in its kernel and was hoping FreeBSD would be better. That was until I saw u_int64_t rather than the standard (and shorter) uint64_t