Date: Sat, 02 Aug 1997 17:00:49 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: FreeBSD-SCSI@FreeBSD.ORG Subject: Phoenix... SCSI Devices Minor Mapping Message-ID: <XFMail.970802170049.Shimon@i-Connect.Net>
next in thread | raw e-mail | index | archive | help
I am sure this subject came up before, more than once.
I have a reason to raise it out of the ashes...
I am dealing with systems with very large databases, some systems will
have up to 8 DPT controllers, 4 busses per controller, 15 SCSI hubs per
bus, 7 devices per hub. This gives us well over 3,000 drives. We need
some certain and predictable mapping between minor so that system
operators can relate /dev name to controller/bus/target. and to hardware
cabinetry.
What I propose is a voluntary standard for wiring down devices, so any
large scale system can be predictable.
The first question to be answered is: How do we want to relate to FCAL
(Fiber Channel Arbitrated Loop)? We can:
a. Ignore it
b. Acomodate it
c. Force it into a conventional mapping.
Of immediate interest is the fact that up to 256 devices can share a
single loop. BTW, performance on these is pretty amazing sight.
Proposal A:
Divide the minor number as follows:
f e d c b a 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| c | c | c | c | b | b | b | b | l | l | l | l | t | t | t | t |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Where t = Target ID
l = Logigal Unit number
b = Bus number
c = Controller number
As you have noticed, the LUN is in a higher bit position than the Target.
Although this breaks down to logical order, it makes most small systems,
using LUN-0-only devices, have something almost identical to the existing
situation.
FCAL can be acomodated by concatenating the LUn and Target fields and
insisting that FCAL devices have no LUNs other than ZERO.
Naming convention:
printf("c%1xb%1xt%1xu%1x", controller, bus, target, lun);
If you noticed, i am avoiding using ``l'' for LUN's as it is too confusing
with ``1''. Also, the order is logically correct.
The kernel's ``unit'' is mapped to the controller in this note.
The channel is determined by:
((xs->sc_link->adapter_bus) % (((unit) + 1) * 8))
The target by:
xs->sc_link->target
and the LUN by:
xs->sc_link->lun
This will allow us up to 16 controllers, 8 busses each, with either 256
bus ID's or 16 Id's with 16 LUNs on each. Should be enough for a release
or two.
Proposal B:
Similar to Proposal A but with complete renaming and the following bitmap:
f e d c b a 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| b | b | b | b | t | t | t | t | t | t | t | t | l | l | l | l |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| - | - | - | - | - | - | - | - | - | - | - | - | c | c | c | c |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Where t = Target ID
l = Logigal Unit number
b = Bus number
c = Controller number
- = Reserved
And a naming mask of "c%1x"b%1xt%02xl%1x"
Any input will be greatly apreciated.
Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970802170049.Shimon>