A    Device Naming Conventions

This chapter discusses the following topics:

• The history of device naming from the old style device naming to the device naming conventions that were introduced in Version 5.0 of the operating system

• Creating device special file names using the new naming conventions

• How device names are assigned including an example of how device names are assigned after moving an existing disk and adding a new disk

• Preserving device names during a Full Installation

• How an Update Installation maps old and current device names

• How to obtain more information about devices attached to your system

A.1    History of Device Naming

In versions of the operating system earlier than Version 5.0 and Version 5.0A, all devices resided in the /dev directory and were named as shown in Table A-1.

Table A-1:  Old Device Naming Conventions

Starting with Version 5.0 of the operating system, each class of device has a separate subdirectory named for the class as shown in Table A-2.

Table A-2:  Version 5.0A Device Naming Conventions

The directory and actual device names are self explanatory, with a few notable exceptions:

disk, rdisk

The disk subdirectory refers to block device nodes. The rdisk subdirectory refers to character device nodes.

tape, ntape

The tape subdirectory refers to rewind-on-close device nodes. The ntape subdirectory refers to no-rewind-on-close device nodes.

Table A-3 shows how old-style device names map to the current device names.

Table A-3:  Mapping of Old Style and New Style Device Names

A.2    Creating Device Special Files

Every time the system is booted, the system hardware is scanned and any new device special files are created automatically. If you add a new device to the system and want to create the device special file without rebooting the system, use the hwmgr command. For example, the following command scans the SCSI bus for any new devices and automatically creates the device special files for any new devices.

# hwmgr -scan scsi

Note

Starting with Version 5.0 of the operating system, the /dev/MAKEDEV command is no longer used to create device special files.

A.3    How Device Names Are Assigned

Each time a new device is created, it is assigned the next available device name. When the system is installed for the first time, the hardware is probed in order to determine the devices that exist on the system. The hardware probe starts at bus 0/target 0 and probes each successive target on bus 0. It then proceeds to probe bus 1 and all of its targets starting from target 0. As each new device is discovered, it is assigned the next available device number, starting from 0. Table A-4 shows a sample device naming scenario:

Table A-4:  Sample Device Naming Scenario

Once a physical disk has been assigned to a device name, it retains that device name, regardless of its position on the bus. Each physical device is given a unique worldwide identifier at the time it is manufactured. It is this worldwide identifier that is used to map the physical device to the new device name. This means that a disk can be moved from slot to slot on the bus without having to change the device name. So, if you move a disk from one slot to another you would continue to refer to the disk using the same device name. Using the example in Table A-4, if the disk known as dsk0 were to move from bus 0/target 0 to bus 1/target 4, the new device name would remain the same. Under previous releases the device would need to be accessed as rz12, but in the new release the device name remains dsk0. This is because the device name is tied to the worldwide identifier and not to the position of the disk on the bus.

Once a device is assigned a new device name, it retains that name across system reboots. New devices are given the next available device name. Continuing the example used in Table A-4, assume that the DEC100 device (dsk0) has been moved from bus 0/target 0 to bus 1/target 4. Also assume that a new device (DEC099) has been added to the system on bus 0/target 0. Table A-5 shows the new device names when the system reboots:

Table A-5:  Device Name Assignments After Moving and Adding a Device

Table A-5 shows that the DEC100 device still retains the dsk0 device name, even though it has moved to another bus/target. The new device (DEC099) has been assigned the next available device name (dsk5). See Section A.6 for information about obtaining device information from the operating system.

A.4    Preserving Device Names During a Full Installation

When a Full Installation is performed, the existing device naming databases are lost. This means that the new device names will be assigned based upon the order in which the devices are found. This new naming scheme may be different from the naming scheme used in older versions of the operating system. However, there is a way to save this information during a Full Installation. This feature is particularly useful if you have applications that use the existing devices names and you intend to run those applications on the new version of the operating system. If you do not preserve the device naming databases, your applications may access the wrong devices. The device names can be preserved across Full Installations using the following steps:

1. Shut down the system to console mode:

   
   # shutdown -h now
   

2. Examine the bootdef_dev console variable:

   >>> show bootdef_dev
   

   If the value of the bootdef_dev variable is set to the disk containing the / (root) file system, the Full Installation procedure automatically preserves the hardware device database and there is no need to do anything. If not, proceed to the next step.

3. Set the value of the bootdef_dev variable if it is not set to the disk containing the / file system:

   >>> set bootdef_dev dka0
   

4. Perform the Full Installation. The Full Installation preserves the device databases from the previous version of the operating system. It does this by mounting the device specified by the bootdef_dev variable and saving the necessary device database files. These files are then placed on the newly created system. This means the devices on the new system will be mapped exactly as they were from the previous installation.

If you do not want to preserve the device naming from the previous installation, set the bootdef_dev console variable to " " (double quotes).

A.5    Update Installation Device Names

The Update Installation maps the old device names to the new device names, so that the new system will have both the old rz* devices and the new dsk* devices. The mapping of the old device names to the new device names can be found in the/etc/dfsl.dat file. This mapping is determined dynamically each time the system is booted. This is because the old device name is based upon the bus and target location while the new device name remains constant. Therefore, if the disk moves from one bus to another bus, the old device name will change, but the new device name will not. See Table A-2 for details on device naming conventions.

Note

The /etc/dfsl.dat file should not be modified. This is a database used by the kernel to access system devices. Modifying this file may render devices inoperable.

As in releases earlier than Version 5.0A, the kernel does not mount the same device more than once. For example, in previous releases of the operating system, you could not mount /dev/rz0a on /mnt and then mount /dev/rz0a on /mnt1. This restriction still applies to Version 5.0A of the operating system. This means that if you have an old device name mounted and attempt to mount the same device using the new device name, the mount will fail. For example, if both /dev/rz0a and /dev/disk/dsk0a map to the same physical disk, you cannot mount both /dev/rz0a and /dev/disk/dsk0a at the same time.

A.6    Obtaining More Device Information

Use the following to retrieve information regarding the state of the hardware

• The SysMan Station lets you monitor one system or a group of systems and administer system resources. You can set the View to see all hardware connected to the system.

  If you are logged in as the root user, the SysMan Station is available from an icon on the CDE front panel. However, to open the SysMan Station from the command line, enter:

  
  # /usr/sbin/sysman -station
  

• The Hardware Manager enables you to manage hardware components and the hardware subsystems that maintain information about hardware components. A hardware component can be a storage peripheral, such as a disk or tape, or a system component such as a CPU or a bus. Use the hwmgr utility to manage hardware components on either a single system or on a cluster.

  The hwmgr utility provides two types of commands, internal and generic. Internal commands do not contain a subsystem identifier on the command line. Generic commands are characterized by a subsystem identifier after the command name.

  The Hardware Manager uses the following generic command syntax:

  /sbin/hwmgr command [subsystem] [parameters]

  For example, use the following command to determine the worldwide IDs of the disks attached to your system:

  # hwmgr -get attribute -category disk
  

  Refer to the hwmgr(8) reference page for more information about the utility and for more command line examples.