Laureate Online Education Operating Systems

© All right reserved, 2002-2006. The Operating Systems module, in all its parts: syllabus,
guidelines, lectures, discussion questions, technical notes, images and any additional
material is copyrighted by Laureate Online Education.

Module: MSC OS-yymmdd-0x Seminar 6

Standard I/O Systems Structure

Note: Sem6Figure1 (referenced in the lecture) is located as an attached file

Objectives:

At the end of the seminar, the student will be able to:

• Identify the basic concepts of I/O systems, as they relate to the hardware interface to the
operating systems
• Describe the typical hardware architecture in terms of servicing devices
• Discuss methods of management of I/O devices and their impact on the operating
systems performance
• Demonstrate an understanding of the interdependence between the three levels of mass
storage structure
• Differentiate between the types of scheduling approaches used to access mass storage
• Identify trends in mass storage devices and how these trends affect operating systems
design

Introduction

In Seminar 5, we discussed the filing system structure and various ways in which the disk is
managed by the operating system. In this seminar, we will be taking a look at all of the other
types of I/O devices, and spend some time with a special focus on disk scheduling.

Devices used by the computer system are of a wide variety and the operating system needs to be
designed in such a way as to accommodate the greatest possible combination of device access
yet keep the structure as simple as possible. Further, the device management subsystem must
provide mechanisms that reduce the chance of a bottleneck, as I/O devices tend to be some of
the slowest components, from a performance perspective.

Modern operating systems attempt to balance these needs through the use of device drivers.
Device drivers (and the specifications that they imply) provide a stable method in which devices
can be accessed through the I/O subsystem, providing an interface for use by the application and
the operating system while masking the “gruesome” details of I/O handling. Device management
must maintain the difficult balance of providing access to a list of devices with finite resources
while servicing an infinite quantity of user requests!
I/O Hardware Concepts

Device management involves basically four main functions:

• Tracking the status of each device, such as tape drives, disk drivers, printers, terminals
• Using preset policies to determine which process will be provided access to which device
and for how long the access will last
• Allocating the devices, according to status and policy
• De-allocating the devices, according to status and policy, and making them available both
at the process and the job level (depending on the device)

System devices generally fall under three main categories: dedicated, shared and virtual. How
physically they are accessed by the software is dependent on the following hardware architecture
concepts:

Ports: Connection points that are generally seen as “one-on-one” communication

Bus: Preset and rigidly enforced common set of communication wires. An example of the PC
Bus architecture is shown in Figure 13.1
Controller: Method of management, through which a port, bus or device is operated. Controllers
range from simple (serial) to complex (SCSI adapter). The controller manages the I/O transfer
through the use of four registers for data and control: Status, Control, Data-On and Data-Out.
The processor communicates using a single or combination approach of special I/O instructions
using device specific addresses, or through the use of memory mapping. Figure 13.2 lists
commonly used port locations for a PC.

Polling is used to determine the state of any device and uses a three-step CPU instruction cycle:
(1) read the device register, (2) extract the status bit and (3) branch back to (1) if it determines
that the bit not to be zero. Only when the status bit equals zero, it can exit the loop of continuous
inquiries and perform the I/O. Given that any device may be busy for an extended period of time,
polling is insufficient as the only way in which access to a device may be obtained.

The device controller uses interrupts to request access to the device. The CPU responds to the
interrupt by jumping to a preset interrupt handler routine and readies the device for access.
However, some processes cannot be stopped and not all devices may be appropriate for the
request. It is the interrupt mechanism responsibility to determine the best course of action. First,
a number is used to access an index to a table maintained by the system, called the interrupt
vector. This list is examined to determine which device can handle the request. Interrupts use
priority levels to manage resource allocation and utilization. Device controllers place interrupts on
the register when they are available for service. You may recall that interrupts are used to
manage privileged instructions and exceptions. Software interrupts (referred to as traps) are
system calls used by the application to convey requests to the kernel, as they are not allowed to
issue privilege instructions. Interrupts are also used to manage the flow of control within the
kernel by splitting interrupts into high priority ones that have to be handled immediately and by
deferring low priority interrupts to a low level interrupt handler that will be executed only when the
CPU is not busy. As you can see, the interrupt mechanism is heavily used and must
accommodate a wide variety of requests, including efficient device access and management.

To support large transfers, such as one involving disk drives, a Direct Memory Access (DMA)
controller is used. The DMA controller makes the request once to the CPU, the CPU responds
and writes the address to the DMA controller, the data transfer commences, without further
intervention by the CPU, while the DMA controller completes the transfer independently. If this
approach were not used, the CPU would be totally responsible for the physical movement of the
data between the memory and the device, decreasing the CPU utilization significantly.
I/O Support for Applications

At the other end of the spectrum, I/O support for applications attempts to hide the specifics of the
device handling from the application, thereby allowing applications to simply make “calls” for
device support and be serviced. The use of device drivers permits simple interface at the
application layer but accommodates the specific device specifications. In reality, each operating
system takes a slightly different approach as to how the interface is presented, thereby requiring
device manufacturers to provide multiple device driver support. Figure 13.6 provides an example
of this type of strategy..

There are many devices with a multitude of features as outlined in figure 13.7. In fact there are so
many different devices that their specific control commands must be masked from the
programmer; much of this is accomplished through the vendor-supplied device drivers.

A block device, such as a disk, requires all aspects of the device to be captured before the device
may be accessed. Memory mapping provides a more efficient means by which block devices can
be serviced using mapped I/O, as the data is moved, using the Virtual Storage mechanism, into
virtual memory and serviced on an “as needed” basis. You may recall from Seminar 4 that the
use of virtual memory also provides an efficient way to service requests to the kernel.

A character stream device such as a keyboard, communicate continually and interactively,

displaying the data on the screen as it is created. On the other hand, video applications use
multiple activities to display data on the screen (file access, extraction, decompression and
display).

Additional devices, such as network devices, have a completely different I/O mechanism, known
as the socket interface, a method with which to exchange data. Clocks and timers offer yet
another kind of a device that measures time, usually by interrupting the CPU tenth of times per
second.

I/O Kernel Support

The kernel provides many of the commonly used services related to I/O: (1) scheduling, (2)
buffering, (3) caching, (4) spooling, (5) device reservation and (6) error handling.

Scheduling: While maintaining a queue for each device, the kernel utilizes algorithms designed
to efficiently accommodate the requests for device. More information on disk algorithms will be
provided later on in the lecture.

Buffering, Caching and Spooling are techniques used to synchronize data movement between
devices or a device and an application. In comparison to the CPU, devices are much slower and
these techniques prevent the “mismatch” of speed with the consequence of reduction of the
efficiency of the overall system. For example, let’s say that data is being transferred from a
relatively slow device, such as a modem. Rather than “tie up” the hard disk, buffers are used to
capture the data and then move the data in one action. Using buffering provides the modem the
ability to continue sending data, even when previously received data is being written to the disk.
Double buffering allows the data to be received without the need to maintain a direct connection
to the receiver of the data. Figure 13.10 show the differences in device speeds and why buffering
is essential for optimum efficiency of data transfer. Buffering is also used to accommodate
differences in device data transfer sizes as well to support the integrity of the data being written
by an application to the disk. Caching is a region of fast memory that holds copies of data, with
the intention that the data will be needed repetitively. Spooling provides a vehicle for holding
output from a device, such as printers and tape devices. It serves two purposes: making use of
fast disks to get the data outputted by the program, rather than sending it to slow devices like
printers and to set up "virtual printers" (serially reusable resources) on the disk (a sharable
resource) so that many printers can be emulated within the multiprogramming environment.
Device registration accommodates the need for a device to have explicit facilities available for
exclusive use. Device error handling can be either temporary or permanent. Each device must
be accommodated according to the nature and type of data transaction. Some operating systems
merely report success or failure as a bit of information, while others may provide detailed
reporting of failures, including the type error, category of failure and resulting response.

The I/O directly impacts performance of a system. Each interrupt, in essence, causes a state
change. Programmed I/O can be more efficient than interrupt-driven I/O, but uses more
overhead. The balancing act between efficiency and servicing of needs is never completely
resolved, but can be assisted by using various approaches:

• Reduce the number of context switches

• Reduce the number of times data must be copied into memory while moving between
devices and applications
• Reduce the frequency of interrupts by using larger transfers, advanced controllers and
polling
• Increase concurrency of activity, using DMA controllers and channels (programmable
units placed between CPU and control units)
• Balance use of CPU, memory, bus and I/O, so that no single element causes others to
remain idle or un-serviced.

Disk Structure, Access & Management:

In Seminar 5, we discussed how files, and the disk they reside on, are managed, from a structure,
access and management perspective. Now we are going to look at how secondary and tertiary
storage structures are managed at the I/O level.

Disks are the main mechanism used for mass storage and are addressed as large, one-
dimensional arrays of logical blocks. These blocks are mapped to sectors, which are organized
by tracks. Disk access time is comprised of seek time, head selection and rotation latency.
Disk scheduling algorithms provide standard approaches by which disk is accessed.
Scheduling algorithms minimize arm movement, mean response time and the variance in
response time. First Come, First Served (FCFS) is the simplest approach, easy to program and
essentially fair to all users, but does not perform any of the three duties in an acceptable manner.
Shortest Seek Time First (SSTF) favours requests that can be accommodated quickly, but may
cause starvation to requests that take longer to complete. SCAN scheduling starts at one end of
the disk and services requests as it moves. Its disadvantage is that as it moves back and forth
from one end to another, each end will get serviced “earlier” and requests in the middle tend to be
serviced “later". In a variation of SCAN, C-SCAN as the arm reaches its last request on it inbound
travel, it travels immediately to the beginning of the disk and starts to scan again. LOOK actively
checks for requests, before continuing to move the arm in any given direction.

Choosing a disk scheduling policy does nothing to address the rotational latency of the disk. Disk
controllers provide some disk scheduling mechanisms designed to alleviate rotational latency.

The operating system is required to provide services for formatting of the device, boot and bad
block management. Swap space management is another low-level responsibility of the operating
system. You may recall that swap space is used for virtual memory management. Location of
swap space may be dictated directly by the operating system parameters and may reside on any
disk partition. Windows 2000, for example, allows for swap space to be located in any available
disk partition.
Disk Redundancy and Stability

Using a variety of disk drive physical combinations can accommodate reliability of data.
Redundancy can be achieved through mirroring (the use of a redundant disk) or through striping
(where data is written across several disks). However, neither of these techniques, in of
themselves, is efficient from a performance perspective. Redundant Array of Inexpensive Disks
(RAID) is a specification that describes different approaches to redundancy, while providing
efficiency. Figure 12.11 describes how each level adds an aspect of redundancy through the use
of a combination of multiple disks, parity and data striping. Raid 0 stores the data in stripping
mode (the bit of each byte are spread over multiple disks), which enhance the performance but
does not add to the data integrity. RAID level 1 provides basic disk mirroring (and doubles the
number of needed disks). The rest of the raids 2- 6 use parity bit checking in different
combinations: dedicated disks (Raid 2), a single additional disk (Raid 3), data stripping plus
parity (Raid 4) and data and parity spread over all the disks (Raid 5). At RAID level 5, which
must have at least 3 physical disks, parity is written across all disks, so that if one disk fails, data
can be reconstructed using the parity located on the other disks. At RAID level 6, Reed-Solomon
codes are used, instead of parity, so that recovery is possible from two disk failures.

Locally attached storage devices are not the only way in which data can be accommodated.
Increasingly common are the use of network attached storage (file servers) that use IPC and
RPC communication methods (as discussed in Seminar 2). Storage Area Networks (SAN)s
organize storage across multiple network implementations so that the data is stored across
multiple systems (not just local disks within one system), yet are accessed using a common
access method. Fibre channel SANs are examples of an emerging technology, where TCP/IP
networks, using Gigabit Ethernet, are used to provide high speed multiple disk access over the
network. See Sem6Figure6 for an example of how networking is providing new ways to access
data storage.

Tertiary Storage disks include any type of storage device that is removable, and include floppy,
zip, CD, Flash Drives, DVD and magnetic tape. The device may or may not have vendor specific
parameters that must be accommodated through the use of device drivers. The increasing use of
laser technology has produced new approaches to managing data, including the use of
holographic storage (used to record images on special media).

Removable media have special needs, due to the nature of their transportability. In order to
provide for appropriate interface to the applications, removable media needs the operating
system to “present” the media to the application when requested by calling for the device on a
sporadic basis. Naming structures, device driver loading and file structure hierarchy must be
loaded at the time the media is called for, instead of relying on the initial boot process to “pre-
load” the parameters.

Finally, tertiary storage must balance the requirements of speed, reliability and cost, if it is fulfill its
role as a stable storage mechanism.

Summary

The operating system support for I/O devices must accommodate a wide variety of structures,
methods for access while providing a stable environment that balances resources and needs.
Device drivers standardize much of the technical needs of the devices, while remaining flexible
enough to work with a variety of operating systems. Internal I/O support by the kernel provides a
stable approach to servicing requests for I/O devices. Algorithms are used for disk scheduling,
and contain ways in which optimum efficiency of device use is coupled with acceptable response
time. As costs for disk continue to fall, various technologies are emerging that present alternative
ways to provide mass storage device support. Seminar 7 will examine some of these trends in
more detail.