Thursday, November 24, 2011

AIX Interview Cheet Sheet

Object Data Manager

It is necessary to know something of the Object Data Manager (ODM) in order to understand the way in which AIX handles devices. The ODM manages object-oriented databases of system information. Among the databases it manages is that of device configuration. This database is made up of two object classes: the predefined object class and the customized object class. The predefined object class contains configuration information for all possible devices supported by AIX, and the customized object class contains information for devices actually on the system.

Object Classes

An object class is a collection of objects with the same definition. Object class definitions resemble C language structures and are found in the /etc/objrepos (short for object repository) directory or in the directory specified by the ODMDIR variable. For example, the object definition for customized devices attached to the system is found in /etc/objrepos/CudDv and can be obtained by typing the odmshow command.
# odmshow  CuDv
class CuDv {
        char name[16];
        short status;
        short chgstatus;
        char ddins[16];
        char location[16];
        char parent[16];
        char connwhere[16];
        link PdDv PdDv uniquetype PdDvLn[48];
        };
Each of the items in the CuDv object class definition is a descriptor. When an object is added to the CuDv object class, values are associated with each of the descriptors. For example, a SCSI hard disk with a location code of 00-00-0S-00 would have this code stored in the location descriptor.

Objects

An object is an item that belongs to an object class. Each object has a set of configuration parameters corresponding to the descriptors in the object class definition. For example, to see the objects and their associated values that make up the CuDv object class, type:
# odmget CuDv
Among the stanzas in the output, you would likely see the following:
CuDv:
    name = "hdisk0"
    status = "1"
    chgstatus = "2"
    ddins = "scdisk"
    location = "00-00-0S-00"
    parent = "scsi0"
    connwhere = "00"
    PdDvLn = "disk/scsi/1000mb"
Each of the above lines corresponds to the CuDv object class definition. The last line is important in that it illustrates the hierarchical classification of devices. As stated earlier, the ODM database consists of more than device data, but within the realm of devices there is similar "class" terminology, which can be confusing at times. In the last line above, for example, disk is the device class, scsi is the device subclass, and 1000mb is the device type.

Device Classes

A device class describes the basic function of the device. For example, there is a device class called adapter, a fairly generic description. A device subclass is a more specific description. sio (standard input/output) and mca (microchannel), for example, are subclasses of the adapter device class. Finally, a device type is the most specific description of the device: keyboard, tablet, mouse, and hscsi are types of the of the sio device subclass, which in turn is a member of the adapter device class.
Although there are many ways to get this information, the following command provides a sorted list of currently defined devices on the system while at the same time illustrating further the concept of device classes:
# lsdev -C -F "class subclass type description" | sort
adapter        mca        ppr        POWER Gt3i Graphics Adapter
adapter        mca        sio_1      Standard I/O Planar
adapter        sio        fda        Standard I/O Diskette Adapter
adapter        sio        hscsi      Standard SCSI I/O Controller
adapter        sio        ient_1     Standard Ethernet Adapter
adapter        sio        keyboard   Keyboard Adapter
adapter        sio        mouse      Mouse Adapter
adapter        sio        ppa        Standard I/O Parallel Port Adapt
adapter        sio        s1a_1      Standard I/O Serial Port 1
adapter        sio        s2a_1      Standard I/O Serial Port 2
adapter        sio        tablet     Tablet Adapter
bus            sys        mca        Microchannel Bus
disk           scsi       1000mb     1.0 GB SCSI Disk Drive
diskette       siofd      fd         Diskette Drive
fpa            sys        fpa1       Floating Point Processor
hft            node       hft        High Function Terminal Subsystem
if             EN         en         Standard Ethernet Network Inter
if             EN         ie3        IEEE 802.3 Ethernet Network Inter
if             LO         lo         Loopback Network Interface
ioplanar       sys        ioplanar_1 I/O Planar
keyboard       sio.kb     kb101      United States keyboard
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume lvsubclass lvtype     Logical volume
logical_volume vgsubclass vgtype     Volume group
lvm            lvm        lvdd       N/A
memory         sys        memory     64 MB Memory Card
mouse          sio.ms     mse_3b     3 button mouse
planar         sys        sysplanar1 CPU Planar
pty            pty        pty        Asynchronous Pseudo-Terminal
sys            node       aio        Asynchronous I/O
sys            node       sys        System Object
sysunit        sys        sysunit    System Unit
tape           scsi       8mm5gb     5.0 GB 8mm Tape Drive
tcpip          TCPIP      inet       Internet Network Extension
As you can probably deduce from the command, the four columns above represent the class, subclass, type, and description of the currently defined objects on the system. Note that although the ppr (POWER Gt3i Graphics Adapter) and fda (Standard I/O Diskette Adapter) both belong to the same adapter device class, they belong to different subclasses: mca and sio, respectively.

Adding Supported Devices

Adding and removing devices requires manipulating the device configuration database via the ODM, a daunting task. If you use AIX device management commands like mkdev, rmdev, lsdev, lsattr, and chdev you need to be familiar with these class concepts and the ODM. However, two tools can greatly simplify the task: the cfgmgr command and SMIT.

cfgmgr

The cfgmgr command, also known as the Configuration Manager, automatically configures devices on the system. It is run twice at system boot and can be run at the command line as well. When invoked, cfgmgr reads rules from the Config_Rules object class. These rules are commands that configure devices and make them available for use by creating device files and installing drivers. To see what these rules are, use the odmget Config_Rules command.
Thus one way of adding, say, an 8mm, 5GB SCSI tape drive is to:
  1. Power down the system
  2. Connect the drive
  3. Power-on the drive
  4. Boot the system
During system boot, cfgmgr will recognize the new device and configure it for use. If you type the following command, you will see that the drive is recognized:
# lsdev -C -c tapermt0 Available 00-00-0S-60 5.0 GB 8mm Tape Drive
The term "Available" refers to the tape drive's state. A device has one of three states: undefined, defined, or available. If the tape drive is undefined, it has not been configured by cfgmgr. If it is defined, its configuration data is recorded in the customized database, but the device is not available for use. Once a defined device is bound to the kernel it is in the available state. cfgmgr will make sure your device is defined and then made available.
cfgmgr can also be run at the command line. If you add a device, such as the above tape drive, to a running system (even if it is a SCSI device), you have to run the cfgmgr command to make it available. Also, if you have an available but powered-down device when you reboot, the cfgmgr during bootup will set the device to a defined state. To make it available, power-on the device and rerun the cfgmgr command.

Adding a Device Using SMIT

You can attach a device to the system, power it on, and then use SMIT to configure it. To do so, just type smit device at the command line. You will see the following:

Devices
Move cursor to desired item and press Enter.

  Configure Devices Added After IPL
  Printer/Plotter
  TTY
  Asynchronous Adapters
  PTY
  Console
  Fixed Disk
  CD ROM Drive
  Diskette Drive
  Tape Drive
  Communication
  High Function Terminal (HFT)
  SCSI Initiator Device
  SCSI Adapter
  Asynchronous I/O
  Multimedia
  List Devices


Just select the item you wish to add and press Enter. If you were to add the example 8mm tape drive to the system this way, you would select Tape Drive. The next screen would look like the following:


Tape Drive
Move cursor to desired item and press Enter.

  List All Defined Tape Drives
  List All Supported Tape Drives
  Add a Tape Drive
  Change / Show Characteristics of a Tape Drive
  Remove a Tape Drive
  Configure a Defined Tape Drive
  Generate Error Report
  Trace a Tape Drive

Select Add a Tape Drive. You will then be presented a list of supported tape drives, something similar to the following:

Tape Drive Type
Move cursor to desired item and press Enter.

     1200mb-c scsi 1.2 GB 1/4-Inch Tape Drive
     150mb    scsi 150 MB 1/4-Inch Tape Drive
     3490e    scsi 3490E Autoloading Tape Drive
     4mm2gb   scsi 2.0 GB 4mm Tape Drive
     4mm4gb   scsi 4.0 GB 4mm Tape Drive
     525mb    scsi 525 MB 1/4-Inch Tape Drive
     8mm      scsi 2.3 GB 8mm Tape Drive
     8mm5gb   scsi 5.0 GB 8mm Tape Drive
     9trk     scsi 1/2-inch 9-Track Tape Drive
     ost      scsi Other SCSI Tape Drive


This list comes from the predefined device object class. If you are adding a non-IBM SCSI tape drive, choose ost scsi Other SCSI Tape Drive. In fact, any time you add an non-IBM SCSI device of any kind, there is always a generic SCSI option in SMIT for you to use. For our example, we will choose 8mm5gb scsi 5.0 GB 8mm Tape Drive. This will produce a dialog asking to choose a parent adapter:

Parent Adapter
Move cursor to desired item and press Enter.

     scsi0 Available 00-00-0S Standard SCSI I/O Controller

Unless you have more than one adapter, you would choose scsi0 Available 00-00-0S Standard SCSI I/O Controller.
Finally, you will get the following screen:

Add a Tape Drive
Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                  [Entry Fields]
Tape Drive type                                    8mm5gb
Tape Drive interface                               scsi
Description                                        5.0 GB 8mm Tape Drive
Parent adapter                                     scsi0
*CONNECTION address                                 []
BLOCK size (0=variable length)                     [1024]              #
Use DEVICE BUFFERS during writes                    yes                +
Use EXTENDED file marks                             no                 +
DENSITY setting #1                                  140                +
DENSITY setting #2                                  20                 +
Use data COMPRESSION                                yes                +

Here the only required entry is the CONNECTION address, which is your SCSI address. Other parameters you can change as needed. Herein is the advantage of adding a device through SMIT: you can customize your configuration. Otherwise, using cfgmgr will add the device with default attributes. If the tape drive in this example is set to SCSI ID 6, you would enter 60 in the CONNECTION address field. [5] Pressing the Enter key at this point will execute the mkdev command and this will configure the drive to an available state.

Adding Unsupported Devices

The predefined object class supports all kinds of devices, most of which are IBM products. However, it does contain generic device objects. To see a list of those objects, enter the following command:
# lsdev -P | grep -i other
printer        opp           parallel      Other parallel printer
disk           osdisk        scsi          Other SCSI Disk Drive
tape           ost           scsi          Other SCSI Tape Drive
tmscsi         tmscsi        scsi          Other SCSI Initiator Device
printer        osp           rs232         Other serial printer
printer        osp           rs422         Other serial printer
cdrom          oscd          scsi          Other SCSI CD-ROM Drive
If your device is not part of the predefined object class and closely resembles one of the above objects, then using one of them when adding a device through SMIT may very well work. Often cfgmgr will do just that when it encounters an unknown device. However, if this doesn't work you have no choice but to modify the predefined object database, write the necessary device methods, write a device driver (if necessary), and install the software to support the driver. Consult Device Driver Kernel Extension Overview in InfoExplorer for more information.

Removing Devices

When you physically remove a device from the system, cfgmgr resets the device state to defined the next time a reboot occurs in case you want to reattach it later. If you want to set the device state to defined without rebooting the system, use the rmdev command. The syntax of the rmdev is:
rmdev -l Name
Name is the logical name of the device. To find the logical names of the customized devices, use the lsdev -C command. The first column of this command's output is the logical names of the devices. Thus, to remove our example 8mm drive you type:
# rmdev -l rmt0
This keeps the rmt0 device configuration information in the customized database but sets its state to defined. To remove the drive entirely from the customized database, type:
# rmdev -d -l rmt0
The above can be done through SMIT. Just type smit device, select your device, and then choose the appropriate menu selection to remove it. You will be prompted as to whether or not you want to keep the device in the customized database.

5.3 HP-UX

HP-UX follows a more traditional method of adding a device: before a device can be used its device driver must be compiled into the kernel. The default kernel configuration of HP-UX will probably meet the needs of most systems. However, to keep the size of the kernel small, some drivers may not be present. If you need to add a device whose driver is not a part of the kernel, you will have to create a new one.

Adding a Device without Modifying the Kernel

The basic steps of doing so are:
  1. Add your device to the system. This usually requires shutting down the system, attaching the device, and rebooting; for SCSI devices it is required.
  2. Determine how the device is to be accessed: block or character (raw) mode. A device file must exist for each type of access to the device.
  3. Determine if the device file necessary to communicate with the device already exists on your HP-UX system.
  4. If the appropriate device file does not exist for the newly installed device, you must create one. If you are using SAM to add your device, SAM will create the device file. If you are not using SAM, use the mknod command to create the device file.

Device Files

Device files provide user-level access to the device drivers found in the kernel. These files are found in the /dev directory. Consider the following command and its output:
#  ls -l  /dev/console  /dev/*dsk
crw--w--w-  1  root    sys    0  0x000000  Apr 16 12:56  /dev/console

/dev/dsk:
total 0
brw-r--r--  1  root    sys    7  0x410200  Apr 16 09:08  c42d0s0
brw-r--r--  1  root    sys    7  0x201600  Jan 14 16:41  c201d6s0

/dev/rdsk:
total 0
crw-r--r--  1  root    sys   47  0x410200  Apr 16 09:08  c42d0s0
crw-r--r--  1  root    sys   47  0x201600  Mar 18 15:30  c201d6s0
The first character of each line identifies the type of device file. A b denotes a block device, and a c indicates a character device. A block device transfers data a block at a time by using the system buffers. A disk drive holding a mountable file system is an example of a block device. A character device reads or writes data one character at a time. Tape drives are usually character devices. Some devices are capable of I/O in both block and character mode. Such devices require two device files: one for block and one for character mode. A hard disk is an example of a device which uses both character and block device files. For purposes of mounting the disk as a file system, you will use the block device file. For purposes of accessing the disk for backups, the character device file is used.
The major and minor numbers appear immediately before the date. The major number identifies what kernel driver is being referred to by the device file. The value chosen for the major number is based on both the device driver and on the access method (block or character). For devices needing both a character and block device file, there are different character major numbers and block major numbers. You can use the lsdev command to list the device drivers and their major numbers in the system. For example:
# lsdev
    Character   Block       Driver
        0        -1     /dev/console
        1        -1     HP98628, HP 98626, and HP98642
        2        -1     /dev/tty
        3        -1     /dev/mem, /dev/kmem, and  /dev/null
       16        -1     Master pty
       17        -1     Slave pty
       23        -1     raw 8042 HIL
       24        -1     HIL
       25        -1     HIL cooked keyboards
       47         7     SCSI disk
       52        -1     IEEE 802 device
      121        -1     SCSI tape
       55        10     Optical Autochanger

The first two columns document character and block major numbers respectively. A -1 in either column means that a major number does not exist for that type of driver. Note that in the example above the SCSI disk driver has both a character and a block major number. Thus a long listing of the device files for such a disk at SCSI address 6 would look like the following:
# ls -l  /dev/*dsk/c201d6s0
/dev/dsk:
total 0
brw-r--r--  1  root    sys    7  0x201600  Jan 14 16:41  c201d6s0

/dev/rdsk:
total 0
crw-r--r--  1  root    sys   47  0x201600  Mar 18 15:30  c201d6s0
The directory containing the block device file, with a major number of 7, is /dev/dsk, and the directory with the character device file in it is /dev/rdsk. (The letter r is used here because character mode is often referred to as "raw" mode; block mode is sometimes called "cooked" mode.) You can also see device major numbers in the /etc/master file.
The minor number is an encryption of address and configuration information. It typically defines one or both of the following: 1) the device's physical address, and 2) operational information, such as tape density or rewind options in the case of tape drives. Note that the minor number and the device file name are similar. There is a reason for that, which brings us to the next topic.

Device File Naming Conventions

HP-UX follows a naming convention for device files which it employs on preloaded systems and when SAM is used to create device files. You can use whatever name you want when you create a device file, but if you follow the naming convention you will find it easier to locate and identify a particular device file. To make the names easier to remember you can create the device file using the naming convention and then link that name to one like /dev/tape1 or /dev/cd.
The device file name for the most common devices begins with the letter c, which stands for the controller number. What follows the letter c is either the number 20, which indicates the core I/O module of the system bus, or 4, indicating the EISA bus adapter. Next is a number indicating function of the controller. The number 1 is for the SCSI function. Next is usually the letter d, which stands for the device number, or bus address. Often there follows additional numbers or letters that indicate additional information. The following are examples of disk device files. The letter s indicates the section number, which is always zero unless software disk striping is used.

/dev/[r]dsk/c201d6s0 SCSI disk on the core I/O module at bus address 6
/dev/[r]dsk/41d3s0 SCSI disk on the EISA slot at bus address 3

The following is an example of an optical autochanger device file:

/dev/[r]ac/c201d3_1a SCSI optical autochanger at bus address 3, disk1, side a

Tape drive device files have the following possible values in addition to the controller number and address number:

h High density of 6250 bpi
m Medium density of 1600 bpi
l Low density of 800 bpi
c Indicates data compression (only for drives that support compression)
n Indicates no rewind upon close of device
b Indicates Berkeley-style tape behavior
525|150|120 Indicates the format of a quarter-inch tape drive

Example tape drive device files:

/dev/rmt/c201d3h SCSI tape drive at bus address 3, high density
/dev/rmt/c201d3mn SCSI tape drive at bus address 3, medium density, no rewind on close


Creating Device Files

You can use SAM to create device files. SAM will create the files using the recommended naming convention, create both block and character versions where needed, and assign the appropriate major and minor numbers. In many cases using SAM to do these tasks is the best way to go, especially in the case of tape drives, since there are often as many as 16 different device files for each one you install. And since the minor numbers are hexadecimal values, using SAM can make things a lot easier.
However, you can create device files manually by invoking the mknod command. The syntax of mknod is:
mknod name c|b major number minor number
Name is the device name, preferably based on the naming convention. The c or b indicates that the file is either a character device file or a block device file, respectively. Major number is derived from either the lsdev command or the /etc/master file. That leaves us with an explanation of how to form the minor number.
The minor number format is 0xSFDDD where:
0x indicates hexadecimal notation (hex is required)
S is the system bus module number. Remember that 20 is for core I/O, and 4 is for EISA.
F is the function number. The function numbers are:
  • 1 for SCSI
  • 2 for LAN
  • 3 for HIL
  • 4 for serial port A
  • 5 for serial port B
  • 6 for parallel port
DDD is more specific information. Its format differs, depending on the driver that is used to communicate with the device.
Driver-specific Designations
Peripheral type Format of DDD Syntax
SCSI disk drive TUV T is the target number (bus address)
U is the unit number for integrated devices
V specifies the volume number (0 for single file systems)
Tape drive TDO T is the bus address D is density flag O is the operation bits
Autochanger TS T is the bus address
S is the surface
Parallel printer T00 T is the bus address
00 is always set to 00

For details on creating the appropriate minor numbers for all devices, see Chapter 14 of Installing Peripherals in the LaserRom documentation.
To help determine the appropriate minor number, you can use the ioscan -f command. ioscan searches the system provides, among other things, the hardware path number for each device it finds, and it is the hardware path number that forms the basis of the minor number. For example:
# ioscan -f
Class      H/W Path  Driver   H/W Status    S/W Status
=======================================================
scsi       2.0.1     c700     ok(0x7071)    ok
disk       2.0.1.1.0 scsi     ok(0x5800202) ok
disk       2.0.1.2.0 scsi     ok(0x201)     ok
tape_drive 2.0.1.3.0 scsitape ok(0x1800202) ok
disk       2.0.1.4.0 scsi     ok(0x201)     ok
disk       2.0.1.6.0 scsi     ok(0x101)     ok
lan        2.0.2     lan01    ok(0x7072)    ok
hil        2.0.3     hil      ok(0x7073)    ok
serial     2.0.4     asio0    ok(0x7075)    ok
serial     2.0.5     asio0    ok(0x7075)    ok
parallel   2.0.6     parallel ok(0x7074)    ok
scsi       4.1.0     c700     ok(0x7680)    ok
disk       4.1.0.4.0 scsi     ok(0x201)     ok
disk       4.1.0.5.0 scsi     ok(0x201)     ok
disk       4.1.0.6.0 scsi     ok(0x201)     ok
For the SCSI disk listed above whose hardware path number is 2.0.1.1.0, for example, the appropriate minor number would be 0x201100. This can be interpreted as follows:

0x Hexadecimal notation
20 The core I/O card on system bus module 2
1 SCSI function number
100 Bus address 1, unit 0, volume 0

Remember, if you have difficulty in coming up with the correct minor number, or any other part of the device file creation process, just use SAM to do it for you

Modifying the Kernel in Order to Add a Device

For most systems, the default kernel configuration is sufficient and you will not have to modify the kernel configuration in order to add a device. However, kernel drivers such as cs80 (Series 300/400/700) and hshpib are not included in the default configuration. These drivers are needed for the optional EISA HP-IB card and its peripherals (for example, to communicate with an HP-IB DDS-format drive). To configure them, you must rebuild the kernel.

Using SAM to Rebuild the Kernel

Using SAM is the easiest way to rebuild the kernel. In the case of devices SAM will also make sure your device files are created. SAM will make changes to the /etc/conf/dfile file, the kernel configuration file, and will use it to build the new kernel. SAM will always show you a list of whatever you are configuring with values in one of two categories: current and pending. The pending values are those you have changed in /etc/conf/dfile and which will be the new kernel values when you have created a new kernel and rebooted the system. The current values are those in the current running kernel.
When you have completed all the kernel changes you wish to make using SAM, you should choose the Create a New Kernel action. When the new kernel has been created, you will be given the choice of 1) moving the kernel into place and rebooting the system immediately, 2) moving the kernel into place but not rebooting the system, or 3) exit without moving the kernel into place.

Rebuilding the Kernel Manually

/etc/conf/dfile contains an entry for all peripheral devices, I/O cards, and major software subsystems such as LAN, RJE, and X25. To add a device, card, or subsystem to the kernel, you must add an entry for it in the dfile. To determine what entry to add to the dfile you should examine /etc/master. The /etc/master file is the device information table that contains the device name, handler name, element characteristics, functions for the device, and major device number. If what you are trying to add is not in the /etc/master file, then it is not supported by HP.
Let's assume you want to add a SCSI floppy drive to your system. First you would check /etc/master to make sure it's supported and then add scsifloppy to the dfile. Assuming your working directory is /etc/conf, you would enter the following commands:
# config dfile
# make -f config.mk
# mv /hp-ux /SYSBCKUP
# mv hp-ux
# cd /
# reboot

5.4 Summary

The handling of device differs greatly between AIX and HP-UX. AIX uses the Object Data Manager to handle devices, and HP-UX uses traditional AT&T-style device files and kernel drivers. The easiest way to add a device in AIX is to connect it to a powered-down system, turn it on, and boot the system. During the boot process the cfgmgr utility is run, which configures the device and adds it to the customized device configuration database. It also runs rules that create the appropriate device files. You can run cfgmgr at the command line or use SMIT to add a device. These two methods ensure that not only the appropriate device files are created, but that the ODM's customized device database is maintained. If you need to add a device not listed in the predefined device database, you can use generic entries that will work. This enables you to add devices without having to rebuild the kernel, something not done in AIX. Also, you normally do not create your device files with the mknod command, even though it exists in AIX.
HP-UX requires that the appropriate driver be included in the kernel. If it is, you just attach the device to the system and create the appropriate device files with the mknod command, although many device files are already created for you in a preloaded system. If the driver is not in the kernel, you must 1) check that the appropriate driver is listed in the /etc/master file, 2) put an entry for that driver in the /etc/conf/dfile file, and 3) rebuild the kernel. After that you can create the appropriate device files. Both creating device files and rebuilding the kernel can be done through SAM, which is often the best way to go because figuring out what minor numbers to use can be a difficult task.
Regardless of how device files are created, both AIX and HP-UX use device files in the same way. These files are special files that provide user-level access to device drivers, so commands like tar can be used to read to and write from tape drives. For example, in AIX you can archive files in the /home directory to tape by typing:
# tar -cvf /dev/rmt0 /home
Or in HP-UX:
# tar cvf /dev/rmt/c201d3mnb
All you have to do is remember the locations of the device files on the respective systems. The following tables will help you do that for the most commonly used devices.
AIX File System Device Files

Block Character
/dev/hd1 /dev/rhd1
/dev/hd2 /dev/rhd2
/dev/hd3 /dev/rhd3
/dev/hd* /dev/hd*

HP-UX File System Device Files

Block Character
/dev/dsk/c201d0s0 /dev/rdsk/c201d0s0
/dev/dsk/c201d1s0 /dev/rdsk/c201d1s0
/dev/dsk/c201d2s0 /dev/rdsk/c201d2s0
/dev/dsk/c201d*s0 /dev/rdsk/c201d*s0

AIX Tape Drive Device Files

File Meaning
/dev/rmt* Rewind on close, no retension on open, high density
/dev/rmt*.1 No rewind on close, no retension on open, high density
/dev/rmt*.2 Rewind on close, retension on open, high density
/dev/rmt*.3 No rewind on close, retension on open, high density
/dev/rmt*.4 Rewind on close, no retension on open, low density
/dev/rmt*.5 No rewind on close, no retension on open, low density
/dev/rmt*.6 Rewind on close, retension on open, low density
/dev/rmt*.7 No rewind on close, retension on open, low density

HP-UX Tape Drive Device Files

File Meaning
/dev/rmt/c201d*c Rewind on close, compress data
/dev/rmt/c201d*cb Rewind on close, compress data, Berkeley style
/dev/rmt/c201d*cn No rewind on close, compress data
/dev/rmt/c201d*cnb No rewind on close, compress data, Berkeley style
/dev/rmt/c201d*h Rewind on close, high density
/dev/rmt/c201d*hb Rewind on close, high density, Berkeley style
/dev/rmt/c201d*hn No rewind on close, high density
/dev/rmt/c201d*hnb No rewind on close, high density, Berkeley style
/dev/rmt/c201d*l Rewind on close, low density
/dev/rmt/c201d*lb Rewind on close, low density, Berkeley style
/dev/rmt/c201d*ln No rewind on close, low density
/dev/rmt/c201d*lnb No rewind on close, low density, Berkeley style
/dev/rmt/c201d*m Rewind on close, medium density
/dev/rmt/c201d*mb Rewind on close, medium density, Berkeley style
/dev/rmt/c201d*mn No rewind on close, medium density
/dev/rmt/c201d*mnb No rewind on close, low density, Berkeley style

Note: High density is 6250 bpi, medium is 1600 bpi, and low is 800 bpi. For AT&T-style devices the tape is positioned after the EOF following the data just read. For Berkeley-style devices, the tape is not repositioned in any way.
AIX Floppy Drive Device Files

Block Character
/dev/fd0 /dev/rfd0

No comments:

Post a Comment