Figure 2. Mapping logical extents to physical extents shows how the logical volumes are mapped onto physical volumes. Each PV consists of a number of fixed-size physical extents (PEs); similarly, each LV consists of a number of fixed-size logical extents (LEs). (LEs and PEs are always the same size, the default in LVM 2 is 4 MB.) An LV is created by mapping logical extents to physical extents, so that references to logical block numbers are resolved to physical block numbers. These mappings can be constructed to achieve particular performance,
scalability, or availability goals.
For example, multiple PVs can be connected together to create a single large logical volume as shown in Figure 3. LVM linear mapping.This approach, known as a linear mapping, allows a file system or database larger than a single volume to be created using two physical disks. An alternative approach is a striped mapping, in which stripes (groups of contiguous physical extents) from alternate PVs are mapped to a single LV, as shown in Figure 4. LVM striped mapping.The striped mapping allows a single logical volume to nearly achieve the combined performance of two PVs and is used quite often to achieve high-bandwidth disk transfers.
Through these different types of logical-to-physical mappings, LVM can achieve four important advantages over raw physical partitions:
1. Logical volumes can be resized while they are mounted and accessible by the database or file system, removing the downtime associated with adding or deleting storage from a Linux server
2. Data from one (potentially faulty or damaged) physical device may be relocated to another device that is newer, faster or more resilient, while the original volume remains online and accessible
3. Logical volumes can be constructed by aggregating physical devices to increase performance (via disk striping) or redundancy (via disk mirroring and I/O multipathing)
4. Logical volume snapshots can be created to represent the exact state of the volume at a certain
point-in-time, allowing accurate backups to proceed simultaneously with regular system operation
Basic LVM commands
Initializing disks or disk partitions
To use LVM, partitions and whole disks must first be converted into physical volumes (PVs) using the pvcreate command. For example, to convert /dev/hda and /dev/hdb into PVs use the following commands:
#pvcreate /dev/hda (or) pvcreate /dev/hdb
If a Linux partition is to be converted make sure that it is given partition type 0x8E using fdisk, then use pvcreate:
Creating a volume group:
Once you have one or more physical volumes created, you can create a volume group from these
PVs using the vgcreate command. The following command:
#vgcreate volume_group_one /dev/hda /dev/hdb
creates a new VG called volume_group_one with two disks, /dev/hda and /dev/hdb, and 4 MB PEs. If both /dev/hda and /dev/hdb are 128 GB in size, then the VG volume_group_one will have a total of 2**16 physical extents that can be allocated to logical volumes.
Additional PVs can be added to this volume group using the vgextend command. The following commands convert /dev/hdc into a PV and then adds that PV to volume_group_one:
#vgextend volume_group_one /dev/hdc
This same PV can be removed from volume_group_one by the vgreduce command:
#vgreduce volume_group_one /dev/hdc
Note that any logical volumes using physical extents from PV /dev/hdc will be removed as well. This raises the issue of how we create an LV within a volume group in the first place.
Creating a logical volume:
We use the lvcreate command to create a new logical volume using the free physical extents in the VG pool. Continuing our example using VG volume_group_one (with two PVs /dev/hda and /dev/hdb and a total capacity of 256 GB), we could allocate nearly all the PEs in the
volume group to a single linear LV called logical_volume_one with the following LVM
#lvcreate -n logical_volume_one --size 255G volume_group_one
Instead of specifying the LV size in GB we could also specify it in terms of logical extents. First we use vgdisplay to determine the number of PEs in the volume_group_one:
#vgdisplay volume_group_one | grep "Total PE"
Total PE 65536
Then the following lvcreate command will create a logical volume with 65536 logical extents and fill the volume group completely:
#lvcreate -n logical_volume_one -l 65536 volume_group_one
To create a 1500MB linear LV named logical_volume_one and its block device special file
/dev/volume_group_one/logical_volume_one use the following command:
#lvcreate -L1500 -n logical_volume_one volume_group_one
The lvcreate command uses linear mappings by default.
Striped mappings can also be created with lvcreate. For example, to create a 255 GB large logical volume with two stripes and stripe size of 4 KB the following command can be used:
#lvcreate -i2 -I4 --size 255G -n logical_volume_one_striped volume_group_one
It is possible to allocate a logical volume from a specific physical volume in the VG by specifying the PV or PVs at the end of the lvcreate command. If you want the logical volume to be allocated from a specific physical volume in the volume group, specify the PV or PVs at the end of the lvcreate command line. For example, this command:
#lvcreate -i2 -I4 -L128G -n logical_volume_one_striped volume_group_one /dev/hda /dev/hdb
creates a striped LV named logical_volume_one that is striped across two PVs (/dev/hda and
/dev/hdb) with stripe size 4 KB and 128 GB in size.
An LV can be removed from a VG through the lvremove command, but first the LV must be unmounted:
#umount /dev/volume_group_one/logical_volume_one lvremove /dev/volume_group_one/logical_volume_one
Note that LVM volume groups and underlying logical volumes are included in the device special file directory tree in the /dev directory with the following layout:
so that if we had two volume groups myvg1 and myvg2 and each with three logical volumes named lv01, lv02, lv03, six device special files would be created:
Extending a logical volume
An LV can be extended by using the lvextend command. You can specify either an absolute size for the extended LV or how much additional storage you want to add to the LVM. For example:
#lvextend -L120G /dev/myvg/homevol
will extend LV /dev/myvg/homevol to 12 GB, while
#lvextend -L+10G /dev/myvg/homevol
will extend LV /dev/myvg/homevol by an additional 10 GB. Once a logical volume has been extended, the underlying file system can be expanded to exploit the additional storage now available on the LV. With Red Hat Enterprise Linux 4, it is possible to expand both the ext3fs and GFS file systems online, without bringing the system down. (The ext3 file system can be shrunk or expanded offline using the ext2resize command.) To resize ext3fs, the following command
will extend the ext3 file system to completely fill the LV, /dev/myvg/homevol, on which it resides.
The file system specified by device (partition, loop device, or logical volume) or mount point must currently be mounted, and it will be enlarged to fill the device, by default. If an optional size parameter is specified, then this size will be used instead.
Differences between LVM1 and LVM2
The new release of LVM, LVM 2, is available only on Red Hat Enterprise Linux 4 and later kernels. It is upwardly compatible with LVM 1 and retains the same command line interface structure. However it uses a new, more scalable and resilient metadata structure that allows for transactional metadata updates (that allow quick recovery after server failures), very large numbers of devices, and clustering. For Enterprise Linux servers deployed in mission-critical environments that require high availability, LVM2 is the right choice for Linux volume management. Table 1. A comparison of LVM 1 and LVM 2 summarizes the differences between LVM1 and LVM2 in features, kernel support, and other areas.
RHEL AS 2.1 support
RHEL 3 support
RHEL 4 support
Transactional metadata for fast recovery
Shared volume mounts with GFS
Cluster Suite failover supported
Striped volume expansion
Max number PVs, LVs
256 PVs, 256 LVs
2**32 PVs, 2**32 LVs
Max device size
8 Exabytes (64-bit CPUs)
Volume mirroring support
Yes, in Fall 2005
(Table 1. A comparison of LVM 1 and LVM 2)
RAID stands for Redundant Array of Inexpensive Disks. This is a solution where several physical hard disks (two or more) are governed by a unit called RAID controller, which turns them into a single, cohesive data storage block.
An example of a RAID configuration would be to take two hard disks, each 80GB in size, and RAID them into a single unit 160GB in size. Another example of RAID would be to take these two disks and write data to each, creating two identical copies of everything.
RAID controllers can be implemented in hardware, which makes the RAID completely transparent to the operating systems running on top of these disks, or it can be implemented in software, which is the case we are interested in.
Purpose of RAID
RAID is used to increase the logical capacity of storage devices used, improve read/write performance and ensure redundancy in case of a hard disk failure. All these needs can be addressed by other means, usually more expensive than the RAID configuration of several hard disks. The adjective Inexpensive used in the name is not without a reason.
The major pluses of RAID are the cost and flexibility. It is possible to dynamically adapt to the growing or changing needs of a storage center, server performance or machine backup requirements merely by changing parameters in software, without physically touching the hardware. This makes RAID more easily implemented than equivalent hardware solutions.
For instance, improved performance can be achieved by buying better, faster hard disks and using them instead of the old ones. This necessitates spending money, turning off the machine, swapping out physical components, and performing a new installation. RAID can achieve the same with only a new installation required. In general, advantages include:
• Improved read/write performance in some RAID configurations.
• Improved redundancy in the case of a failure in some RAID configurations.
• Increased flexibility in hard disk & partition layout.
The problems with RAID are directly related to their advantages. For instance, while RAID
can improve performance, this setup necessarily reduces the safety of the implementation. On the other hand, with increased redundancy, space efficiency is reduced. Other possible problems
with RAID include:
• Increased wear of hard disks, leading to an increased failure rate.
• Lack of compatibility with other hardware components and some software, like system imaging programs.
• Greater difficulty in performing backups and system rescue/restore in the case of a failure.
• Support by operating systems expected to use the RAID.
RAID introduces a higher level of complexity into the system compared to conventional disk layout. This means that certain operating systems and/or software solutions may not work as intended. A good example of this problem is the LKCD kernel crash utility, which cannot be used in local dump configuration with RAID devices.
The problem with software limitations is that they might not be apparent until after the system has been configured, complicating things.
To sum things up for this section, using RAID requires careful consideration of system needs. In home setups, RAID is usually not needed, except for people who require exceptional performance or a very high level of redundancy. Still, if you do opt for RAID, be aware of the pros and cons and plan accordingly.
This means testing the backup and imaging solutions, the stability of installed software and the ability to switch away from RAID without significantly disrupting your existing setup.
In the section above, we have mentioned several scenarios, where this or that RAID configuration may benefit this or that aspect of system work. These configurations are known as RAID levels and they govern all aspects of RAID benefits and drawbacks, including read/write performance, redundancy and space efficiency.
There are many RAID levels. It will be impossible to list them all here. For details on all available solutions, you might want to read the Wikipedia article on the subject. The article not only presents the different levels, it also lists the support for each on different operating systems.
In this tutorial, we will mention the most common, most important RAID types, all of which are fully supported by Linux.
RAID 0 (Striping)
This level is achieved by grouping 2 or more hard disks into a single unit with the total size equaling that of all disks used. Practical example: 3 disks, each 80GB in size can be used in a
240GB RAID 0 configuration.
RAID 0 works by breaking data into fragments and writing to all disk simultaneously. This significantly improves the read and write performance. On the other hand, no single disk contains the entire information for any bit of data committed. This means that if one of the disks fails, the entire RAID is rendered inoperable, with unrecoverable loss of data.
RAID 0 is suitable for non-critical operations that require good performance, like the system partition or the /tmp partition where lots of temporary data is constantly written. It is not suitable for data storage.
RAID 1 (Mirroring)
This level is achieved by grouping 2 or more hard disks into a single unit with the total size equaling that of the smallest of disks used. This is because RAID 1 keeps every bit of data replicated on each of its devices in the exactly same fashion, create identical clones. Hence the name, mirroring. Practical example: 2 disks, each 80GB in size can be used in a 80GB RAID 1 configuration. On a side note, in mathematical terms, RAID 1 is an AND function, whereas RAID 0 is an OR.
Because of its configuration, RAID 1 reduced write performance, as every chunk of data has to be written n times, on each of the paired devices. The read performance is identical to single disks. Redundancy is improved, as the normal operation of the system can be maintained as long as any one disk is functional. RAID 1 is suitable for data storage, especially with non-intensive I/O tasks.
This is a more complex solution, with a minimum of three devices used. Two or more devices are configured in a RAID 0 setup, while the third (or last) device is a parity device. If one of the RAID 0 devices malfunctions, the array will continue operating, using the parity device as a backup. The failure will be transparent to the user, save for the reduced performance.
RAID 5 improves the write performance, as well as redundancy and is useful in mission-critical scenarios, where both good throughput and data integrity are important. RAID 5 does induce a slight CPU penalty due to parity calculations.
This is a less common level, although fully usable. Linear is similar to RAID 0, except that data is written sequentially rather than in parallel. Linear RAID is a simple grouping of several devices into a larger volume, the total size of which is the sum of all members. For instance, three disks the sizes of 40, 60 and 250GB can be grouped into a linear RAID the total size of
Linear RAID provides no read/write performance, not does it provide redundancy; a loss of any member will render the entire array unusable. It merely increases size. It's very similar to LVM. Linear RAID is suitable when large data exceeding the individual size of any disk or partition must be used.
There are several other levels available. For example, RAID 6 is very similar to RAID 5, except that it has dual parity. Then, there are also nested levels, which combine different level solution in a single set. For instance, RAID 0+1 is a nested set of striped devices in a mirror configuration. This setup requires a minimum of four disks.
These setups are less common, more complex and more suitable for business rather than home environment, therefore we won't talk about those in this tutorial. Still, it is good to know about them, in case you ever need them.