Device Files

Device Files

Device files are special files that represent devices in Solaris 9. Device files reside in the /dev directory, and its subdirectories (such as /dev/dsk), while the /devices directory is a tree that completely characterizes the hardware layout of the system in the file system namespace. Although it may seem initially confusing that separate directories exist for devices and for system hardware, the difference between the two systems will become apparent in the discussion that follows. Solaris refers to both physical and logical devices in three separate ways, with physical device names, physical device files, and logical device names. Physical device names are easily identified because they are long strings that provide all details relevant to the physical installation of the device. Every physical device has a physical name. For example, an SBUS could have the name /sbus@1f,0, while a disk device might have the name /sbus@1f,0/SUNW,fas@2,8800000/sd@1,0. Physical device names are usually displayed at boot time and when using selected applications that access hardware directly, such as format. On the other hand, physical device files, which are located in the /devices directory, comprise an instance name that is an abbreviation for a physical device name, which can be interpreted by the kernel. For example, the SBUS /sbus@1f,0 might be referred to as sbus, and a device disk /sbus@1f,0/SUNW,fas@2,8800000/sd@1,0 might be referred to as sd1. The mapping of instance names to physical devices is not hardwired: the /etc/path_to_inst file always contains these details, keeping them consistent between boots. For an Ultra 2, this file looks like this:

/devand /devicesDirectories

In addition to physical devices, Solaris also needs to refer to logical devices. For example, physical disks may be divided into many different slices, so the physical disk device will need to be referred to using a logical name. Logical device files in the /dev directory are symbolically linked to physical device names in the /devices directory. Most user applications will refer to logical device names. A typical listing of the /dev directory has numerous entries that look like the following:

/dev/console represents the console device-error and status messages are usually written to the console by daemons and applications using the syslog service (described in Chapter 20). /dev/console typically corresponds to the monitor in text mode; however, the console is also represented logically in windowing systems, such as OpenWindows, where the command server%cmdtool-C brings up a console window.

/dev/hme is the network interface device file.

/dev/dsk contains device files for disk slices.

/dev/ttyn and /dev/ptyn are the n terminal and n pseudoterminal devices attached to the system.

/dev/null is the endpoint of discarded output to which many applications pipe their output.

The drvconfig command creates the /devices directory tree, which is a logical representation of the physical layout of devices attached to the system, and pseudodrivers. drvconfig is executed automatically after a reconfiguration boot. It reads file permission information for new nodes in the tree form /etc/minor_perm, which contains entries like this:

sd:* 0666 httpd staff

where sd is the node name for a disk device, 0666 is the default file permission, httpd is the owner, and staff is the group.

Storage Devices

Solaris 9 supports many different kinds of mass-storage devices, including SCSI hard drives (and IDE drives on the x86 platform), reading and writing standard and rewritable CD-ROMs, Iomega Zip and Jaz drives, tape drives, DVD-ROM, and floppy disks. Hard drives are the most common kinds of storage devices found on a Solaris 9 system, ranging from individual drives used to create system and user file systems to highly redundant, server-based RAID systems. These RAID configurations can comprise a set of internal disks, managed through software (such as DiskSuite), or high-speed external arrays like the A1000, which include dedicated RAM for write caching. Because disk writing is one of the slowest operations in any modern server system, this greatly increases overall operational speed.

Hard drives have faced stiff competition in recent years, with new media such as Iomega's Zip and Jaz drives providing removable media for both random and sequential file access. This makes them ideal media for archival backups, competing with the traditional magnetic tape drives. The latter have largely been replaced in modern systems by the digital DAT tape system, which has high reliability and data throughput rates (especially the DDS-3 standard).

In this section, we look at the issues surrounding the installation and configuration of storage devices for Solaris 9, providing practical advice for installing a wide range of hardware.

CD-ROMs

A popular format of read-only mass storage on many servers is the compact disc read-only memory (CD-ROM). Although earlier releases of Solaris worked best with Sun-branded CD-ROM drives, as of Solaris 2.6, Solaris fully supports all SCSI-2 CD-ROMs. For systems running older versions of Solaris, it may still be possible to use a third-party drive, but the drive must support 512-byte sectors (the Sun standard). A second Sun default to be aware of is that CD-ROMs must usually have the SCSI target ID of 6, although this limitation has again been overcome in later releases of the kernel. However, a number of third-party applications with 'autodetect' functions may still expect to see the CD-ROM drive at SCSI ID 6.

A number of different CD formats are also supported with the mount command, which is used to attach CDs to the file system. It is common to use the mount point /cdrom for the primary CD-ROM device in Solaris 9 systems, although it is possible to use a different mount point for mounting the device by using a command-line argument to mount.

Zip and Jaz Drives

There are two ways to install Zip and Jaz drives: by treating the drive as a SCSI disk, in which case format data needs to be added to the system to recognize it, or to use Andy Polyakov's ziptool, which will format and manage protection modes supported by Zip 100 and Jaz 1GB/2GB drives. Both of these techniques only support SCSI and not parallel port drives.

Treating the Zip 100 SCSI drive or the Jaz 1GB drive as a normal SCSI device is the easiest approach, because there is built-in Solaris 9 support for these SCSI devices. However, only standard, non-write-protected disks can be used.

Tape Drives

Solaris 9 supports a wide variety of magnetic tapes using the 'remote magtape' (rmt) protocol. Tapes are generally used as backup devices, rather than as interactive storage devices. What they lack in availability, they definitely make up for in storage capacity- many digital audio tape (DAT) drives have capacities of 24GB, making it easy to perform a complete backup of many server systems on a single tape. This removes the need for late-night monitoring by operations staff to insert new tapes when full (as many administrators will have experienced in the past).

Device files for tape drives are found in the /dev/rmt directory. They are numbered sequentially from 0, so default drives will generally be available as /dev/rmt/0.

To back up to a remote drive, use the command ufsdump, which is an incremental file system dumping program. For example, to create a full backup of the /dev/ rdsk/ c0t1d0s1 file system to the tape system /dev/rmt/0, simply use the following command:

# ufsdump 0 /dev/rmt/0 /dev/rdsk/c0t1d0s1

This command specifies a level 0 (that is, complete) dump of the file system, specifying the target drive and data source as /dev/rmt/0 and /dev/rdsk/c0t1d0s1, respectively. Other devices like 0c and 0cb may also be used.

Floppy Disks

Floppy disk drives (1.44MB capacity) are standard on both SPARC and Intel architecture systems. In addition, by using the Volume Manager, detecting and mounting floppy disks is straightforward. Insert the target disk into the drive, and use this command:

# volcheck

This will check all volumes that are managed by volume management and will mount any valid file system that is found. The mount point for the floppy drive is determined by the settings in /etc/vfstab:

fd - /dev/fd fd - no -

Refer to the section on entering disk information into the virtual file system database for more details on configuring the /etc/vfstab file. A very useful feature of the volcheck command is to automatically check for new volumes; for example,

# volcheck -i 60 -t 3600 /dev/diskette0 &

works in the background to check every minute if a floppy is in the drive. However, this polling takes place only for one hour unless renewed.

CD-ROMs and DVD-ROMs

CD-ROMs are supported directly by the operating system in SPARC architectures and do not require any special configuration, other than the usual process of initializing the system for a reconfiguration reboot: powering down the system, attaching the CD-ROM device to the SCSI bus, and powering on the system. It is not necessary to use format or newfs to read the files on the CD-ROM, nor is it usually necessary to manually mount the file system, because the volume manager (vold) is usually enabled on server systems.

A common problem for Solaris x86 users is that there are few tested and supported CD-ROM brands for installing the operating system (although most fully compliant ATA/ATAPI CD-ROMs should work). The older Sound Blaster IDE interface for CD-ROMs does not appear to be suitable, although support may be included in a later release (the Alternate Status register is apparently not implemented on the main integrated circuit for the controller board). It is always best to check the current Hardware Compatibility List (HCL) on the Sun developer site.

Many recent SPARC and Intel systems come installed with a DVD-ROM drive. Although the drive cannot be yet used to play movies, it can be effectively used as a mass storage device, with a capacity equal to several individual CD-ROMs. Future releases of Solaris may include a DVD player and support for the newer DVD-RAM technology.

CD-Rs and CD-RWs

Solaris 9 supports both reading and writing CD-ROMs. In addition to the CD-R (CD-Readable) format, Solaris 9 also supports CD-RW (CD-ReWritable), previously known as CD-Erasable. It is a new optical disc specification created by the industry organization OSTA (www.osta.org). You can hook up many different SCSI CD-R and CD-RW devices to a SPARC system on SCSI device ID 6, and they will function as normal CD-ROM drives. Although the technical ability to support any SCSI-based device is a given for the operating system, a potentially limiting factor for nonstandard hardware is usually finding software to adequately support it. Luckily, many different open source and commercial editions of CD-recording software are available for the Solaris platform. To obtain support for both Solaris 1.x and 2.x, the best application is cdrecord, by Jörg Schilling, which you can download from ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ . It is freeware, and it makes use of the real-time scheduler in Solaris. It also compiles on the Solaris x86 platform, and can create both music and data discs. It has a rather clunky command-line interface, but it has more features than some of the commercial systems, including the capability to simulate a recording for test purposes (-dummy option); using a single CD for multiple recording sessions (-multi option); manually fixing the disk, if you want to view data from an open session on a normal CD-ROM (-fix option); and setting the recording speed factor (-speed option). If you prefer a commercial system, GEAR for UNIX is also available (http://www.gearcdr.com/html/products/gear/unix/index.html ), as well as Creative Digital Research's CDR Publisher (http://www.cdr1.com/), which is available through Sun's Catalyst program. For more general information about the CD recording process, see Andy McFadden's very comprehensive FAQs at http://www.fadden.com/cdrfaq/.

Adding Devices

In many cases, adding new devices to a Solaris system is straightforward because most devices connect to the SCSI bus, which is a standard interface. The steps involved are usually: preparing the system for a reconfiguration boot, powering down the system, connecting the hardware device, noting the SCSI device number, powering on the system, and using the format command (if necessary) to create a file system. In this section, we examine the procedure for adding disks to both SPARC and Intel architecture machines and highlight potential problems that may occur.

Hard Drives

Hard disk installation and configuration on Solaris 9 is often more complicated than other UNIX systems. However, this complexity is required to support the sophisticated hardware operations typically undertaken by Solaris systems. For example, Linux refers to hard disks using a simple BSD-style scheme: /dev/hdn are the IDE hard disks on a system, and /dev/sdn are the SCSI hard disks on a system, where n refers to the hard disk number. On Linux, a system with two IDE hard disks and two SCSI hard disks will therefore have the following device files configured:

/dev/hda
/dev/hdb
/dev/sda
/dev/sdb

Partitions created on each drive are also sequentially numbered: if /dev/hda is the boot disk, it may contain several partitions on the disk, reflecting the basic UNIX system directories:

Instead of simply referring to the disk type, disk number, and partition number, the device filename for each partition ('slice') on a Solaris disk contains four identifiers: controller (c), target (t), disk (d), and slice (s). Thus, the device file,

/dev/dsk/c0t3d0s0

identifies slice 0 of disk 0, controller 0 at SCSI target ID 3. To complicate matters further, disk device files exist in both the /dev/dsk and /dev/rdsk directories, which correspond to block device and raw device entries, respectively. Raw and block devices refer to the same physical partition, but are used in different contexts: using raw devices allows only operations of small amounts of data, whereas a buffer can be used with a block device to increase the data read size. It is not always clear whether to use a block or raw device interface, but low-level system commands (like the fsck command, which performs disk maintenance) typically use raw device interfaces, whereas commands that operate on the entire disk (such as df, which reports disk usage) will most likely use block devices.

To install a new hard drive on a Solaris system, just follow these steps:

Prepare the system for a reconfiguration boot by issuing the following command:

server# touch /reconfigure

Synchronize disk data and power down the system using these commands:

server# sync; sync; sync; shutdown

Switch off power to the system and attach the new hard disk to the external SCSI chain, or install it internally into an appropriate disk bay.

Check that the SCSI device ID does not conflict with any existing SCSI devices. If a conflict exists, simply change the ID using the switch.

Power on the system and use the boot command in this manner to load the kernel if the OpenBoot monitor appears:

ok boot

The next step (assuming that you have decided which partitions you want to create on your drive), using the information supplied earlier, is to run the format program. In addition to creating slices, format also displays information about existing disks and slices and can be used to repair a faulty disk. When format is invoked without a command-line argument,

# format

it displays the current disks and asks the administrator to enter the number of the disk to format. Selecting a disk for formatting at this point is nondestructive, so even if you make a mistake, you can always exit the format program without damaging data. For example, on a SPARC-20 system with three 1.05G SCSI disks, format opens with this screen:

It is also possible to pass a command-line option to format, comprising the disk (or disks) to be formatted-for example:

# format /dev/rdsk/c0t2d0

After selecting the appropriate disk, the message

[disk formatted]

will appear if the disk has previously been formatted. This is an important message, because it is a common mistake to misidentify a target disk from the available selection of both formatted and unformatted disks. The menu looks like this:

The purpose of formatting is to identify defective blocks and mark them as bad, and generally to verify that the disk is operational from a hardware perspective. Once this has been completed, new slices can be created and sized by using the partition option at the main menu:

format>> partition

In this case, we want to create a new slice 5 on disk 0 at target 3, which will be used to store user files when mounted as /export/home, and corresponding to block device /dev/dsk/c0t3d0s5. After determining the maximum amount of space available, enter that size in gigabytes (in this case, 1.05GB) when requested to do so by the format program for slice 5 (enter 0 for the other slices). If the disk is not labeled, you will also be prompted to enter a label, which contains details of the disk's current slices (useful for recovering data). This is an important step, because the operating system will not be able to find any newly created slices unless the volume is labeled. To view the disk label, use the prtvtoc command. Here's the output from the primary drive in an x86 system:

After saving the changes to the disk's partition table, using label, exit the format program and create a new UFS file system on the target slice by using the newfs command:

# newfs /dev/rdsk/c0t3d0s5

After a new file system is constructed, it is ready to be mounted. First, a mount point is created

# mkdir /export/home

followed by the appropriate mount command:

# mount /dev/dsk/c0t3d0s5 /export/home

At this point, the disk is available to the system for the current session. However, if you want the disk to be available after reboot, you need to create an entry in the virtual file systems table, which is created from /etc/vfstab file. An entry like this,

/dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /export/home ufs 2 yes -

contains details of the slice's block and raw devices, the mount point, the file system type, instructions for fsck, and most importantly, a flag to force mount at boot.

For an x86 system, the output of format looks slightly different, given the differences in the way that devices are denoted:

at the OpenBoot prompt, or by using these commands from a superuser shell:

server# touch /reconfigure
server# sync; sync; init 6

The drive should now be visible to the system. To actually use the drive to mount a volume, insert a Zip or Jaz disk into the drive prior to booting the system. After booting, run the format program:

# format

Assuming that the sd number for your drive is 3, select this sd as the disk to be formatted. Create the appropriate partition using the partition option, then create an appropriate label for the volume and quit the format program.

Next, create a new file system on the drive by using the newfs command-for example:

# newfs -v /dev/sd3c

After creating the file system, you can mount it by typing

# mount /dev/sd3c /mount_point

where /mount_point is something self documenting (such as /zip or /jaz). You need to create this before mounting by typing the following:

# mkdir /zip

or

# mkdir /jaz

An alternate and more flexible approach is to use the ziptool program, which is available at http://fy.chalmers.se/~appro/ziptool.html. Ziptool supports all Zip and Jaz drive protection modes, permits unconditional low-level formatting of protected disks, disk labeling, and volume management for Solaris 2.6 and later. The program has to be executed with root privileges regardless of the access permissions set on SCSI disk device driver's entries in /devices. Consequently, if you want to let all users use it, you must install it as set-root-uid:

# /usr/ucb/install -m 04755 -o root ziptool /usr/local/bin

However, you should note that running setuid programs has security implications.

After downloading and unpacking the sources, you can compile the program by using this:

# gcc -o ziptool ziptool.c -lvolmgt

Of course, you will need to ensure that the path to libvolmgt.a is in your LD_LIBRARY_PATH (usually /lib)

ziptool device command

where device must be the full name of a raw SCSI disk file, such as /dev/rsdk/c0t5d0s2, and command is one or more of the following:

rw

Unlocks the Zip disk temporarily.

RW

Unlocks the Zip disk permanently.

ro

Puts the Zip disk into read-only mode.

RO

Puts the Zip disk into a read-only mode that is password protected.

WR(*)

Protects the disk by restricting reading and writing unless a password is entered.

eject

Ejects the current Zip disk.

noeject

Stops the Zip disk being ejected.

You can find further information on installing Jaz and Zip drives on the Iomega support web site:

Checking for Devices

Obtaining a listing of devices attached to a Solaris system is the best way to begin examining this important issue. In Solaris, you can easily obtain system configuration information, including device information, by using the print configuration command,

# prtconf

on any SPARC or Intel architecture system. On an Ultra 5 workstation, the system configuration looks like this:

Never panic about the message that a driver is 'not attached' to a particular device. Because device drivers are loaded only on demand in Solaris 9, only those devices that are actively being used will have their drivers loaded. When a device is no longer being used, the device driver is unloaded from memory. This is a very efficient memory management strategy that optimizes the use of physical RAM by deallocating memory for devices when they are no longer required. In the case of the Ultra 5, we can see that devices like the PCI bus and the IDE disk drives have attached device drivers, and they were being used while prtconf was running.

At Boot Time

The OpenBoot monitor has the ability to diagnose hardware errors on system devices before booting the kernel. This can be particularly useful for identifying bus connectivity issues, such as unterminated SCSI chains, but also for basic functional issues such as whether devices are responding. Issuing the command,

ok reset

will also force a self-test of the system.

Just after booting, it is useful to review the system boot messages, which you can retrieve by using the dmesg command or by examining the /var/log/messages file. This displays a list of all devices that were successfully attached at boot time, and it also displays any error messages that were detected. Let's look at the dmesg output for a SPARC Ultra architecture system:

Output from dmesg shows that the system first performs a memory test, sets the Ethernet address for the network interface, and then initializes the PCI bus. Setting the Ethernet address is critical on SPARC systems, because the Ethernet interfaces will have the same address stored in PROM. An IDE disk is then recognized and mapped into a physical device, and the appropriate partitions are activated. The standard input devices (keyboard and mouse) are then activated, and the boot sequence is largely complete. However, the output is slightly different for the x86 system:

While the System Is Up

If you are working remotely on a server system, and you are unsure of the system architecture, the command

# arch -k

returns sun4u on the Ultra 5 system, but sun4m on a SPARC 10 system. For a complete view of a system's device configuration, you may also want to try the sysdef command, which displays more detailed information concerning pseudodevices, kernel loadable modules, and parameters. Here's the sysdef output for an x86 server:

The key sections in the sysdef output are details of all devices, such as the PCI bus and pseudodevices for each loadable object path (including /kernel and /usr/kernel). Loadable objects are also identified, along with swap and virtual memory settings. Although the output may seem verbose, the information provided for each device can prove to be very useful in tracking down hardware errors or missing loadable objects.