Software components of the I/O channel

A storage I/O incorporates a number of software components, which handle the logical view of the storage I/O path. They include the following:

򐂰 Application software 򐂰 Operating system

򐂰 File systems and database systems 򐂰 Volume managers

򐂰 Device or network drivers

Application software

Applications which need access to data generate an I/O. The I/O request may come from an interactive user-driven application, a batch process, a database operation, or a system management process. The application has no idea about the physical structure and organization of the storage device where the data is located.

Bus Topology Loop Topology Switched Topology

Data Networks Thinnet Ethernet Token Ring 10BaseT

Thicknet Ethernet FDDI 100BaseT

Arcnet 1000BaseT

ATM

Storage Connection

FC Point-to-Point FC-Arbitrated Loop FC Switched Fabric

Parallel SCSI SSA ESCON

Operating system (OS)

Sometimes it is the operating system (OS) which generates an I/O, using virtual techniques to move data to and from storage as determined by an internal task scheduler. This may include OS components such as system logs, configuration files, and so on. The operating system manages resources and task scheduling.

File systems and database systems

Most I/O requests are handed by the OS to a file system. But many database I/Os bypass the file system and use raw disk partitions.

File systems

A

file system

(FS) is the physical structure an operating system uses to store and organize files on a storage device. At the basic I/O system (BIOS) level, a disk partition contains sectors, each with a number (0,1,2 and so on). Each partition could be viewed as one large dataset, but this would result in inefficient use of disk space and would not meet application requirements effectively. To manage how data is laid out on the disk, an operating system adds a hierarchical

directory structure. Each directory contains files, or further directories, known as sub-directories. The directory structure and methods for organizing disk

partitions is called a file system.

File systems manage storage space for data created and used by the

applications. The primary purpose of an FS is to improve management of data by allowing different types of information to be organized and managed separately. The FS is implemented through a set of operating system commands that allow creation, management, and deletion of files. A set of subroutines allows lower level access, such as open, read, write, and close to files in the file system. The FS defines file attributes (read only, system file, archive, and so on), and allocates names to files according to a naming convention specific to the file system. The FS also defines maximum size of a file and manages available free space to create new files.

Many different file systems have been developed to operate with different operating systems. They reflect different OS requirements and performance assumptions. Some file systems work well on small computers; others are designed to exploit large, powerful servers. An early PC file system is the File Allocation Table (FAT) FS used by the MS-DOS operating system. Others file systems include the High Performance FS (HPFS), initially developed for IBM OS/2, Windows NT File System (NTFS), Journal File System (JFS) developed for the IBM AIX OS, and General Parallel File System (GPFS), also developed by IBM for AIX. There are many others.

A file system does not work directly with the disk device. A file system works with abstract logical views of the disk storage, which are created by the volume manager function. In other words, the disk may be virtual or real. From the file system’s point of view it does not matter. The FS maintains a map of the data on the disk drives, including virtual volumes. From this map the FS finds space which is available to store the file. It then converts the original file I/O request to storage protocols (some number of block I/O operations). Finally, the FS creates metadata (data describing the file) which is used for systems and storage management purposes, and determines access rights to the file.

A disk drive may have partitions with file systems belonging to several different operating systems. Generally an operating system will ignore those partitions whose ID represents an unknown file system.

The file system is usually tightly integrated with the OS. However, in storage networks it may be separated from the OS and distributed to multiple remote platforms. This is to allow a remote file system (or part of a file system) to be accessed as if it were part of a local file system. Later we will see how this happens with Network File System (NFS) and Common Internet File System (CIFS).

Database systems

A database can access and store data by making I/O requests via a file system. Alternatively, it can manage its own block I/O operations by reading and writing directly to “raw partitions” on the disk device. In this case the database allocates and manipulates the storage for its own table spaces without requesting services from the file system. This may result in very much faster performance.

The roles of these components are described in more detail in 2.7, “Tracing the I/O path for local storage” on page 98.

Volume manager

The volume manager may be an integral part of the OS, or it may be a separate software module, such as Veritas Logical Volume Manager developed for Sun Solaris OS. The volume manager is concerned with disk device operations, creating and configuring disk drive partitions into logical drives. The File System uses these logical views to place the data. For instance, the volume manager can mirror I/O requests to duplicate partitions, to provide redundancy and improve performance. In this case, it takes a single I/O request from the file system and creates two I/O requests for two different disk devices. Also, it can stripe data across multiple drives to achieve higher performance; and it may implement RAID algorithms to create fault-tolerant arrays of disk volumes.

The volume manager may have the ability to merge several disk partitions to create a single, virtual volume. This “disk concatenation” delivers a logical volume with the combined capacity of the several partitions. The volume

manager may also use system memory to provide disk caching for increased I/O performance.

Device and network drivers

The driver depends on connection to a channel (bus) or network.

Device driver

For DAS and SCSI block I/O on SAN and iSCSI networks, the device driver software (or firmware) receives the I/O request from the volume manager function. It formats the data and generates the appropriate signal for the targeted storage device. It is the last software in the server to handle the data before it leaves the hardware, and the first to handle it when it returns from the storage device.

Network driver

In the case of network-attached devices, I/O must pass through the network interface card (NIC) attachment to the network. The NIC contains a network protocol driver in firmware. This describes the operations exchanged over the underlying network protocol (such as TCP/IP). There are often several protocol layers implemented here as a series of “device drivers.”

One of the layers is the file protocol driver software, which varies according to the operating system environment. For instance, with Windows operating systems the file protocol is CIFS; with UNIX it is NFS. Or it may be File Transfer Protocol (FTP). These network file system protocol drivers interface to the TCP/IP stack. CIFS and NFS are described in 2.6, “Network file system protocols” on page 93.

In document IP Storage Networking: (Page 107-110)