| Now that we've successfully added the disk, we can start to add the tape drive. We'll do this while the system is alive, but we need to bear a few things in mind: Whether we can add devices to a live system depends upon the hardware supporting this functionality. It's always better to add devices by taking the machine down when possible. If it isn't down, we need to be extra careful about allocating the correct SCSI ID and trying to ensure that the SCSI bus is as quiet as possible.
First, we need to assign a SCSI ID to it, making sure that it doesn't conflict with anything else on the bus. By convention, these are normally target 4 for the first tape and target 5 for the second, so we'll use 4 for this one, since it's our first tape drive to be connected. Drvconfig and Devfsadm Once the tape drive is physically connected, we need to notify the system that it is accessible. Two commands are available to do this. Prior to Solaris 7, drvconfig and its associated commands were used; since Solaris 8, another command, devfsadm, has been used. To add the tape using the original commands, we would issue the following: helium# drvconfig helium# tapes helium# devlinks helium# To perform the same operation with devfsadm, we would use the following command: helium# devfsadm c tape helium# Instead of having to call drvconfig (to configure the /devices tree), tapes (to create the /dev entries for the tape), and lastly devlinks (to create the /dev links), we can simply call devfsadm with the correct class (tape, in this case). It will then go ahead and create everything as required. We can use the same procedure for all class types it supports, which are as follows: The main difference between the two command sets is that devfsadm is much more reliable and allows the devices to be configured with fewer problemsit even works well when the bus is busy. For this reason, if devfsadm is available the system will always use it; in fact, after Solaris 8, drvconfig, tapes, and so forth are simply links back to devfsadm. That was easy! The physical devices have been created under /devices, the instance mapping file /etc/path_to_inst has been updated, and lastly the correct logical entries have been created in /dev. Checking the Tape Now we should be able to check that the tape is working correctly. We'll use the mt command to do this. We need to make sure there is a tape in the drive first; otherwise, we'll see errors reported saying that the drive is "offline": helium# mt -f /dev/rmt/0 stat HP DDS-4 DAT (Sun) tape drive: sense key(0x6)= Unit Attention residual= 0 retries= 0 file no= 0 block no= 0 helium# Nonstandard Tape Drives That was easy enough, but how do we add a tape drive that is unsupported by Solaris or even alter some of the parameters of one of the standard tapes? Let's show this by assuming that we have a new tape device. We'll update the kernel files so that the tape is supported, which will also show how a standard supported tape can be altered. The tape we will add is a "New Everlasting Tape," which has the characteristics shown in Table 17.3. This data should be easily available from each tape manufacturer. Table 17.3. Tape Drive Hardware SpecificationSetting | Value |
|---|
Name | "Everlasting Tape" | Density Switches | 0x14, 0x15 | Fast Wide SCSI | 20 | Ultra SCSI | 20 | Ultra SCSI | 20 |
Configuring St.conf The file /kernel/drv/st.conf is very similar to sd.conf that we saw earlier in that it is used to set configuration parameters for the SCSI tape drive. It also allows us to create additional tape drive entries if we wish. The first step in the process is to get the vendor identification string for the device. If we don't know what this is already, we'll have to go to the PROM level to obtain it by running a probe-scsi, which we'll do here: helium# init 0 ok> ok> probe-scsi Target 3 Unit 0 Disk SEAGATE ST15230W SUN4.2G 0738 Target 5 Unit 0 Removable Tape EVER_LASTING 1000 ok> We can see that we have allocated SCSI ID 5 to the tape and plugged it onto the internal bus. The probe-scsi has queried the PROM on the device to see what it is, and the device has responded by returning its vendor and revision strings. We need to make a note of these, as they are needed for the /kernel/drv/sd.conf entry. The additions to the file are shown below: helium# cat /kernel/drv/st.conf Tape-config-list= "EVER_LASTING", "Everlasting 8mm", "Ever_Last", <lines removed for clarity> # # CONFIGURATION STRINGS SECTION - # Ever_Last = 1,0x36,0,0xCE39,4,0x14,0x1B,0x8C,0x8C,1; <lines removed for clarity> helium# So what does all this mean? The device details consist of two entries. The first, which is "tape-config-list," consists of three parts, which are described in Table 17.4. Table 17.4. Tape-config-list DetailsValue | Description |
|---|
EVER_LASTING | This is the SCSI inquiry string, which we obtained from the output of the probe-scsi. | Everlasting 8mm | Often known as the "pretty print string," this is used for any output relating to the device, such as messages in /var/adm/messages. | Ever_Last | This is a token that identifies the entry containing the properties for the drive. |
We can see from this that the SCSI inquiry string is the only one that is fixed; the other two can be altered as we wish. Table 17.5 shows what is in the device property string. Table 17.5. Device Property DetailsValue | Description |
|---|
1 | The version number. Currently, this should always be set to 1. | 0x36 | The type of device. The full list is specified in /usr/include/sys/mtio.h. We've stated that ours is a "MT_ISOTHER," which is used for a "generic other type of tape drive." | 0 | The preferred block size of the device. Zero is used to specify that it's a variable block-size device. | 0xCE39 | A bit pattern specifying the device capability. These are defined in /usr/include/sys/scsi/targets/stdef.h. We have specified the following capabilities; ST_VARIABLE, ST_BSF, ST_BSR, ST_LONG_ERASE, ST_KNOWS_EOD, ST_UNLOADABLE, ST_SOFT_ERROR_REPORTING, ST_BUFFERED_WRITES, and ST_NO_RECSIZE_LIMIT. | 4 | The number of densities that the device supports. | 0x14, 0x1B, 0x8C, 0x8C | The density switches from the hardware manual. This drive uses 0x14 for no compression, 0x1B for medium compression, and 0x8C for maximum compression. | 1 | The default density (starting at 0). |
Now that we have specified the correct details, let's reboot the system for the changes to take effect and see how the values chosen are used. We'll see the device being reported in the bootup messages as expected, but this time we'll see our "pretty print string": helium# init 6 <lines removed for clarity> st1 at esp0: target 5 lun 0 st1 is /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/st@5,0 <Everlasting 8mm> <lines removed for clarity> This shows that the tape has been recognized and its entry correctly picked up from st.conf. From there, the same steps as adding any "normal" device have been followeda physical device, an instance number (st1), and a logical device have been created. The first thing would be to see how mt reports it: helium# mt -f /dev/rmt/1 stat Everlasting 8mm tape drive: sense key(0x6)= Unit Attention residual= 0 retries= 0 file no= 0 block no= 0 helium# The entry in sd.conf also specified that the device has four density switches. The devices will again be created in the same way as the "normal" tape devices. Table 17.6 shows how the density switch relates to the tape device. Table 17.6. Density SwitchesTape Device | Compression Level | Density Switch Used |
|---|
/dev/rmt/1l | Low | 0x14 | /dev/rmt/1m | Medium | 0x1B | /dev/rmt/1h | High | 0x8C | /dev/rmt/1c | Compressed | 0x8C | /dev/rmt/1 (default) | Medium | 0x1B |
| 
