Chapter 13: Managing Storage Volumes

Overview

The system uses disks to store data, and you learned about disk management in Chapter 5. A file system resides on a slice of a disk and hence cannot span across multiple disks. In other words, the size of a file system is limited by the size of a single disk. Another drawback of treating disks individually and independent of each other is that if a disk crashes, we permanently lose the data that has not yet been backed up, and we cannot continue to serve the data until the disk has been replaced or repaired. In other words, our system is not fault tolerant, and this is not an acceptable environment for 24 × 7 services.

The solution to these problems begins with looking at the disks in terms of logical volume, which is a named chunk of disk space that can occupy a part of a disk or the whole disk; alternatively, it can span across multiple disks that are called a disk set. The concept of logical volume not only opens up practically unlimited disk space for a file system spanned across multiple disks: it also enables two more significant features. First, the availability of abundant disk space makes it possible to provide data replication, thereby implementing fault tolerance. Second, because a volume can span across multiple disks, we can write to multiple disks simultaneously to improve performance. These two features are implemented in a technology called Redundant Array of Inexpensive Disks (RAID). Different ways of implementing these features have given rise to what are called RAID levels. The volumes with these features are called RAID volumes, and Solaris offers a tool called Solaris Volume Manager (SVM) to manage these volumes.

The core issue to think about in this chapter is: how do we perform volume management in Solaris? In search of an answer, we will explore three thought streams: RAID levels, SVM concepts, and state databases, which hold the information about the disk sets and the volumes.