Certification Objective 5.01Understanding Disk Architecture


Certification Objective 5.01—Understanding Disk Architecture

Exam Objective 2.2: Explain disk architecture including the UFS file system capabilities and naming conventions for devices for SPARC, x64, and x86-based systems.

In addition to the operating system, the persistent data largely reside on hard disks. Therefore, a hard disk is an important device on your Solaris system that you will be managing as a system administrator. It is important to understand the disk architecture, which includes the disk geometry and naming conventions for the disks.

Understanding a Disk's Geometry

To understand how data, organized into file systems, reside on a disk and how disk management is performed, you need to understand the geometry of a disk and how it works. The basic unit of a hard disk is a platter made of a material, such as aluminum or glass, on which data can be stored by creating magnetic patterns. The geometry of such a platter is shown in Figure 5-1.

image from book
Figure 5-1: A disk platter with tracks and sectors

As shown in Figure 5-2, a disk drive may consist of a stack of several platters that spin together. Different elements of a disk are described here:

  • Track. A platter is divided into concentric circles called tracks.

  • Sector. The smallest storable unit on a track is called a sector. The storage capacity of a sector is typically 512 bytes.

  • Cylinder. A cylinder consists of a set of tracks with the same radius, one from each platter from the stack. For example, if each platter has 300 tracks, there will be three 300 cylinders on the disk. Assuming the disk has three platters, each cylinder will consist of three tracks if only one side of the platter is used.

  • Disk controller. The disk controller consists of a chip and its circuitry, which instructs the read/write head to move across the platter to read or write data.

  • Disk label. The disk label is the first disk sector that contains information about disk geometry and partitions. We will discuss disk labels and partitions further on in this chapter.

image from book
Figure 5-2: A disk with tracks, sectors, and cylinders

The read/write heads move across the disk surfaces inward or outward to get to the right cylinder, and the disk spins on a spindle to get to the right sector.

The operating system stores the data in files, which are made up of one or more blocks. Therefore, the data is transferred to and from disks in units of blocks. A file block may occupy one or more sectors. The UNIX file system (UFS) uses the following kinds of blocks:

  • Boot block. Contains the information for booting the system.

  • Superblock. Contains information about the file system.

  • Inode. Contains information about one file in the file system.

  • Data block. Contains the data for a file.

In order to work with disks, you will need to refer to them by their names. To understand the disk names, you will need to understand the device-naming conventions defined in Solaris, which we explore next.

Understanding Naming Conventions for Devices

The devices—including disks—in Solaris are referenced by their names, called device names. There are three kinds of device names in Solaris that we discuss in this section. When a device is first added to the system, a name with a full path in the device hierarchy tree is created, and this name is called the physical device name. However, the kernel and the system administrators refer to the devices by convenient names called instance names and logical device names, respectively.

Physical Device Names

A physical device name represents the device name with full path in the device information hierarchy tree. This name for a device is created when the device is first added to the system; the corresponding device files are created in the /devices directory and are controlled by the devfs file system.

You can display the physical device names by using any of the following commands:

  • dmesg. The basic function is to look into the system buffer for recently printed diagnostic messages and print them on the standard output.

  • format. Basically a disk partition and maintenance utility.

  • prtconf. A utility to print system configuration.

  • sysdef. A utility that outputs the system definition.

Note that dmesgd has been made obsolete by syslogd to maintain the system error log. The kernel, however, uses the abbreviated names for these devices, called instance names, which we discuss next.

Instance Names

An instance name is the kernel abbreviated name for a device, and the kernel has them for all possible devices on the system. For example, sd0 and sd1 are the instance names of two disk devices. The mapping between the instance names and the physical device name is contained in the following file:

    /etc/path_to_inst 

You can display the instance names by using the following commands:

  • dmesg

  • prtconf

  • sysdef

Remember, however, that of these commands, only the dmesg command displays the mapping between the physical device names and the instance names. Of course, you can see the mapping by displaying the content of the /etc/path_to_inst file as well—for example, by issuing the following command:

    less /etc/path_to_inst 

Although the kernel uses the instance names to refer to the device, you, the system administrator, use the logical names, which we explore next.

Logical Device Names

When a device is first added to the system, a logical device name is created in addition to the physical device name. Logical device files live in the /dev directory whereas the physical device files live in the /devices directory. Just like instance names, the logical device names point to the physical device names. You, the system administrator, will use the logical device names to refer to the devices in various system commands.

There is a slight difference between the structure of a logical name on a SPARC-based system and on an x86-based system, as is discussed next.

Logical Device Names on SPARC-Based Systems The structure of a logical device name on a SPARC-based system is shown in Figure 5-3. We describe here the different components of the name:

  • Device directory. This refers to the top directory for the devices—that is /dev.

  • Block or raw disk. This refers to the rdsk subdirectory for raw device interface that transfers data one character at a time, and the dsk subdirectory for block device interface that transfers data in buffers.

  • Logical controller number. This refers to the disk controller number. The system assigns a number to each controller in the order it was discovered. If there is only one controller, this number is usually 0.

  • Physical bus target number. This is the disk number that the controller uses to address each disk individually. Each disk under a controller has a unique target number.

  • Drive number. This is the logical unit number of the disk. For single disks the number is always 0, but in a group of disks (e.g., in SCSI disk arrays), this number uniquely identifies a disk in the group.

  • Slice number. This number uniquely identifies a slice (partition) on a disk. We will discuss slices (partitions) further on in this chapter.

image from book
Figure 5-3: The structure of a logical device name for a device on a SPARC-based system

On the Job 

Logical controller numbers are assigned automatically during system initialization. The numbers are strictly logical, and are assigned in the order the controller is discovered. For example the controller discovered first may be numbered 1, and the controller discovered second may be named 2, and so on.

Note that disk drives have entries under both /dev/dsk and /dev/rdsk directories. An entry in /dev/rdsk refers to a raw device. In this case the data is transferred to and from the device one character at a time, and it bypasses the system's I/O buffers. A raw device is used only for small data transfers. In contrast, an entry in the /dev/dsk directory refers to a block (or buffered) device, and the system in this case uses I/O buffers to speed up the data transfer.

As Table 5-1 shows, some commands require the specific interface type (blocked or raw) to use in referring to a device in the command. For example, you must use the raw interface type in the fsck command as shown here:

    fsck /dev/rdsk/c0t0d0s0 

Table 5-1: Device interface types required by some commonly used commands

Command Name

Device Interface Type

Example of Use

df

Block

 df /dev/dsk/c0t0d0s0 

fsck

Raw

 fsck /dev/rdsk/c0t0d0s0 

mount

Block

 mount /dev/dsk/c1t0d0s? /home 

newfs

Raw

 newfs /dev/rdsk/c0t3d0s6 

prtvtoc

Raw

 prtvtoc /dev/rdak/c0t0d0s3 

There are two kinds of controller—direct controllers and bus-oriented controllers. Direct controllers, such as an IDE controller, access the disk directly, whereas a bus-oriented controller, such as a SCSI controller, accesses the disk through the bus. SPARC-based systems use the same scheme, the bus-oriented logical name scheme discussed in this section for both kinds of controllers. For direct controllers, the physical bus target number is usually set to 0.

image from book
Exam Watch

The SPARC-based systems always use the same logical device name scheme for both direct and bus-oriented controllers, whereas x86-based systems use different schemes for direct controllers and bus-oriented controllers.

image from book

Disk devices with direct controllers and bus-oriented controllers are named differently on x86 systems, which we explore next.

Logical Device Names on x86-Based Systems On x86-based systems, the logical names for disk devices with bus-oriented controllers, such as SCSI controllers, are determined following the same scheme as in SPARC-based systems. However, the structure of a logical name for a disk device with direct controllers, such as an IDE controller, is slightly different, as is shown in Figure 5-4. Note that this figure is identical to Figure 5-3 except that the bus target number element is missing.

image from book
Figure 5-4: Structure of a logical device name for a disk with a direct controller, such as an IDE controller, on an x86-based system

Now that you know how to format a disk and how it is named by the system, see the next page for some practical scenarios and their solutions.

In this section, we have explored how the disk platters are divided into different elements and how to name a disk device. Dividing the disk into tracks and sectors is called low-level formatting. Once a disk has gone through low-level formatting, it is ready for partitioning, which is a process of grouping cylinders together into a slice on which a file system will reside.

SCENARIO $ SOLUTION

How would you refer to the third partition on a disk connected to a SPARC-based Solaris system with bus target number 0, logical unit number 0, and controller number 2?

 C2t0d0s3 

How would you refer to this slice in the fsck command?

 /dev/rdsk/c2t0d0s3 

How would you refer to this slice in the mount command?

 /dev/dsk/c2t0d0s3 




Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX
Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net