Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Absolute BSD - The Ultimate Guide To FreeBSD (2002).pdf
Скачиваний:
29
Добавлен:
17.08.2013
Размер:
8.15 Mб
Скачать

components because the signal will stop.

While it may seem like a pain to find and use external terminators, do so if possible. External termination will save you trouble later when you have to replace a drive.

Note Don't put SCSI devices along the cable in a "Y" format. The bus must be in a straight line. Some cables look like they allow you to do this, but these cables are deceptive and should not be used in this way.

SCSI IDs and LUNs

A SCSI ID is an address the bus uses to tell signals within the computer where to go. Each device has a unique SCSI ID that identifies it along the bus. On a raw physical level, the bus tags each piece of data with the SCSI ID of its destination. Each SCSI ID must be unique in most systems, and if you have identical ones along the chain, the first device to boot will grab the ID.

Each possible port on the bus has a unique ID. Since this is a computer system, those ID numbers begin with 0 and end at either 7 or 15, depending on the bus. The adapter is typically SCSI ID 7.

Some SCSI systems also support Logical Unit Numbers, or LUNs. This is a clever trick to make it possible to have multiple devices share one SCSI ID. If every component in your SCSI system supports LUNs, you can use them, but every device that shares a SCSI ID must have a unique LUN.

Managing your SCSI system is like sending mail. The bus number is like the city. Your SCSI ID is the street address. If multiple buildings share the same street address, the delivery man will drop his package at the first one he sees. Similarly, the LUN is like an apartment number. (You don't want your packages dropped in the lobby.) If every device on your system has a unique SCSI address, you'll be fine. If it doesn't, stop everything and make sure it does.

FreeBSD and SCSI

To use SCSI properly with FreeBSD, you'll need to make some kernel changes (see Chapter 4). There are two basic kernel tasks you need to handle: the boot−time SCSI delay and wiring down devices.

Boot−Time Delay

A SCSI system includes all sorts of intelligent chips to handle data flow along the bus, which can take longer to power up and enable than IDE hardware. As such, FreeBSD includes a delay in the boot process to allow this to happen, and this is controlled by the SCSI_DELAY option:

...............................................................................................

options SCSI_DELAY=8000

...............................................................................................

The time given, in milliseconds, is set by default to 15000 (or 15 seconds). The amount of time your system requires will depend on your hardware. A delay of 15 seconds is a generous estimate for older hardware. If you have newer SCSI equipment, you can probably reduce this to 5 seconds or so. If you have problems, of course, turn it back up. Using a 15−second delay doesn't hurt anything, and it doesn't indicate problems.

384

Wiring Down Devices

The other annoyance is that the FreeBSD kernel numbers the SCSI devices based on the order in which they're found. (Every operating system has to deal with SCSI booting behavior in some way, and this is simply BSD's way.) As such, if you change the devices on your SCSI bus, you could change the order in which they are probed: What was disk 0 when you installed BSD could become disk 1 after you add a new tape drive. This change would cause partitions to be mounted on the wrong mount points.

You can have similar problems with SCSI buses–if you add another SCSI card, your buses can be renumbered! As you might imagine, unmitigated chaos results from either of these problems.

To prevent this problem, you can hard−code this information into the kernel to prevent future confusion, a process called wiring down the SCSI devices. To wire down the device, you need the SCSI ID, SCSI bus number, and LUN (if used) of each device on your SCSI chain, available at /var/run/dmesg.boot.

For example, on a test system, I have the following dmesg entries for my SCSI adapter:

...............................................................................................

ahc0: <Adaptec aic7880 Ultra SCSI adapte> port 0xac00−0xacff mem 0xd9000000−0xd9000fff irq 11 a

aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs

...............................................................................................

The first line of this output shows us that the main SCSI card is an "Adaptec aic7880 Ultra" adapter. The second line gives us more information about the adapter on this card. This is really only one physical card. (You learn a lot about what's actually inside your computer hardware by examining dmesg, don't you?) The host adapter is using SCSI ID 7, and no LUN. By opening the case and looking at the physical card, I can verify that there's only one SCSI bus.

A little later in the dmesg file, I have these entries for my disks:

...............................................................................................

...

v da0 at w ahc0 x bus 0 y target 2 z lun 0

...

@ da1 at ahc0 bus 0 target 8 lun 0

...

...............................................................................................

This tells us that the disk da0 (v) is on the SCSI card ahc0 (w). We also know that it is on bus 0 (x). The "target" is the SCSI ID 2 (y). Finally, the LUN of this drive is 0 (z). The second SCSI disk ({) is on the same SCSI card, on the same bus, and has the same LUN. Its SCSI ID is 8, however.

To wire down a drive, tell the kernel exactly where each disk lives so that the kernel doesn't have to guess how a SCSI device should be numbered:

...............................................................................................

385