On 12/10/13 17:41, 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".
We're following the path-of-least-resistance from Solaris. I've
momentarily forgotten how this works in the Linux patches, but the
approach is as follows (this has actually been in HEAD for a couple
months now). Extended LUNs are stored in host byte order with swizzled
16-bit word order so that, for devices implementing LUN addressing (like
SCSI-2), the numerical representation of the LUN is identical before and
after the change. Thus this keeps most behavior, and user-facing LUN
IDs, unchanged. A macro (CAM_EXTLUN_BYTE_SWIZZLE) is provided to
transform a lun_id_t into a uint64_t ordered for the wire.
Most of the kernel prints these in hex as per SAM5. camcontrol prints
them out in various ways if it knows the addressing component to which
they correspond and otherwise prints them in hex. This seemed like by
far the least painful approach: it has a (fairly) simple direct mapping
onto the wire format, nothing changes for users, and almost nothing
changes for code.
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.
Hopefully this corresponds to that advice, whatever it was :) Any
suggestions for changes would be appreciated if you have them.
-Nathan
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
CAM is old still, so I've tried to keep the existing style. Updates are
probably a good idea.
-Nathan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
