Managing Disk Space with LVM
by Bryce Harrington and Kees Cook
04/27/2006
The Linux Logical Volume Manager (LVM) is a mechanism for virtualizing disks. It can create "virtual"
disk partitions out of one or more physical hard drives, allowing you to grow, shrink, or move those
partitions from drive to drive as your needs change. It also allows you to create larger partitions than
you could achieve with a single drive.
Traditional uses of LVM have included databases and company file servers, but even home users may
want large partitions for music or video collections, or for storing online backups. LVM and RAID 1 can
also be convenient ways to gain redundancy without sacrificing flexibility.
This article looks first at a basic file server, then explains some variations on that theme, including
adding redundancy with RAID 1 and some things to consider when using LVM for desktop machines.
LVM Installation
An operational LVM system includes both a kernel filesystem component and userspace utilities. To turn
on the kernel component, set up the kernel options as follows:
Device Drivers --> Multi-device support (RAID and LVM)
[*] Multiple devices driver support (RAID and LVM)
< > RAID support
<*> Device mapper support
< > Crypt target support (NEW)
You can usually install the LVM user tools through your Linux distro's packaging system. In Gentoo, the
LVM user tools are part of the lvm2 package. Note that you may see tools for LVM-1 as well (perhaps
named lvm-user). It doesn't hurt to have both installed, but make sure you have the LVM-2 tools.
LVM Basics
To use LVM, you must understand several elements. First are the regular physical hard drives attached
to the computer. The disk space on these devices is chopped up into partitions. Finally, a filesystem is
written directly to a partition. By comparison, in LVM, Volume Groups (VGs) are split up into logical
volumes (LVs), where the filesystems ultimately reside (Figure 1).
Each VG is made up of a pool of Physical Volumes (PVs). You can extend (or reduce) the size of a
Volume Group by adding or removing as many PVs as you wish, provided there are enough PVs
remaining to store the contents of all the allocated LVs. As long as there is available space in the VG,

you can also grow and shrink the size of your LVs at will (although most filesystems don't like to shrink).
1
Figure 1. An example LVM layout (Click to view larger image)
Example: A Basic File Server
A simple, practical example of LVM use is a traditional file server, which provides centralized backup,
storage space for media files, and shared file space for several family members' computers. Flexibility is
a key requirement; who knows what storage challenges next year's technology will bring?
For example, suppose your requirements are:
400G - Large media file storage
50G - Online backups of two laptops and three desktops (10G each)
10G - Shared files
Ultimately, these requirements may increase a great deal over the next year or two, but exactly how
much and which partition will grow the most are still unknown.
Disk Hardware
Traditionally, a file server uses SCSI disks, but today SATA disks offer an attractive combination of
speed and low cost. At the time of this writing, 250 GB SATA drives are commonly available for around
$100; for a terabyte, the cost is around $400.
SATA drives are not named like ATA drives (hda, hdb), but like SCSI (sda, sdb). Once the system has
booted with SATA support, it has four physical devices to work with:
/dev/sda 251.0 GB
/dev/sdb 251.0 GB
/dev/sdc 251.0 GB
/dev/sdd 251.0 GB
Next, partition these for use with LVM. You can do this with fdisk by specifying the "Linux LVM"
partition type 8e. The finished product looks like this:
# fdisk -l /dev/sdd
2
Disk /dev/sdd: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Start End Blocks Id System
/dev/sdd1 1 30515 245111706 8e Linux LVM
Notice the partition type is 8e, or "Linux LVM."
Creating a Virtual Volume
Initialize each of the disks using the pvcreate command:
# pvcreate /dev/sda /dev/sdb /dev/sdc /dev/sdd
This sets up all the partitions on these drives for use under LVM, allowing creation of volume groups. To
examine available PVs, use the pvdisplay command. This system will use a single-volume group
named datavg:
# vgcreate datavg /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
Use vgdisplay to see the newly created datavg VG with the four drives stitched together. Now create
the logical volumes within them:
# lvcreate --name medialv --size 400G
# lvcreate --name backuplv --size 50G
# lvcreate --name sharelv --size 10G
Without LVM, you might allocate all available disk space to the partitions you're creating, but with LVM,
it is worthwhile to be conservative, allocating only half the available space to the current requirements.
As a general rule, it's easier to grow a filesystem than to shrink it, so it's a good strategy to allocate
exactly what you need today, and leave the remaining space unallocated until your needs become
clearer. This method also gives you the option of creating new volumes when new needs arise (such as
a separate encrypted file share for sensitive data). To examine these volumes, use
the lvdisplay command.
Now you have several nicely named logical volumes at your disposal:
/dev/datavg/backuplv (also /dev/mapper/datavg-backuplv)
/dev/datavg/medialv (also /dev/mapper/datavg-medialv)
/dev/datavg/sharelv (also /dev/mapper/datavg-sharelv)
Managing Disk Space with LVM
Pages: 1, 2, 3, 4
Selecting Filesystems
Now that the devices are created, the next step is to put filesystems on them. However, there are many

types of filesystems. How do you choose?
3
For typical desktop filesystems, you're probably familiar with ext2 and ext3. ext2 was the standard,
reliable workhorse for Linux systems in years past. ext3 is an upgrade for ext2 that providesjournaling,
a mechanism to speed up filesystem checks after a crash. ext3's balance of performance, robustness,
and recovery speed makes it a fine choice for general purpose use. Because ext2 and ext3 have been
the defaults for such a long time, ext3 is also a good choice if you want great reliability. For storing
backups, reliability is much more important than speed. The major downside to ext2/ext3 is that to grow
(or shrink) the filesystem, you must first unmount it.
However, other filesystems provide advantages in certain situations, such as large file sizes, large
quantities of files, or on-the-fly filesystem growth. Because LVM's primary use is for scenarios where you
need extreme numbers of files, extremely large files, and/or the need to resize your filesystems, the
following filesystems are well worth considering.
For large numbers of small files, ReiserFS is an excellent choice. For raw, uncached file I/O, it ranks at
the top of most benchmarks, and can be as much as an order of magnitude faster than ext3.
Historically, however, it has not proven as robust as ext3. It's been tested enough lately that this may
no longer be a significant issue, but keep it in mind.
If you are designing a file server that will contain large files, such as video files recorded by MythTV,
then delete speed could be a priority. With ext3 or ReiserFS, your deletes may take several seconds to
complete as the filesystem works to mark all of the freed data blocks. If your system is recording or
processing video at the same time, this delay could cause dropped frames or other glitches. JFS and XFS
are better choices in this situation, although XFS has the edge due to greater reliability and better
general performance.
With all these considerations in mind, format the partitions as follows:
# mkfs.ext3 /dev/datavg/backuplv
# mkfs.xfs /dev/datavg/medialv
# mkfs.reiserfs /dev/datavg/sharelv
Mounting
Finally, to mount the file systems, first add the following lines to /etc/fstab:
/dev/datavg/backuplv /var/backup ext3 rw,noatime 0 0

/dev/datavg/medialv /var/media xfs rw,noatime 0 0
/dev/datavg/sharelv /var/share reiserfs rw,noatime 0 0
and then establish and activate the mount points:
# mkdir /var/media /var/backup /var/share
# mount /var/media /var/backup /var/share
Now your basic file server is ready for service.
Adding Reliability With RAID
So far, this LVM example has been reasonably straightforward. However, it has one major flaw: if any of
your drives fail, all of your data is at risk! Half a terabyte is not an insignificant amount to back up, so
this is an extremely serious weakness in the design.
4
To compensate for this risk, build redundancy into the design using RAID 1. RAID, which stands for
Redundant Array of Independent Disks, is a low-level technology for combining disks together in various
ways, called RAID levels. The RAID 1 design mirrors data across two (or more) disks. In addition to
doubling the reliability, RAID 1 adds performance benefits for reads because both drives have the same
data, and read operations can be split between them.
Unfortunately, these benefits do not come without a critical cost: the storage size is cut in half. The
good news is that half a terabyte is still enough for the present space requirements, and LVM gives the
flexibility to add more or larger disks later.
With four drives, RAID 5 is another option. It restores some of the disk space but adds even more
complexity. Also, it performs well with reads but poorly with writes. Because hard drives are reasonably
cheap, RAID 5's benefits aren't worth the trouble for this example.
Although it would have made more sense to start with a RAID, we waited until now to introduce them so
we could demonstrate how to migrate from raw disks to RAID disks without needing to unmount any of
the filesystems.
In the end, this design will combine the four drives into two RAID 1
pairs: /dev/sda +/dev/sdd and /dev/sdb + /dev/sdc. The reason for this particular arrangement is
thatsda and sdd are the primary and secondary drives on separate controllers; this way, if a controller
were to die, you could still access the two drives on the alternate controller. When the
primary/secondary pairs are used, the relative access speeds are balanced so neither RAID array is

slower than the other. There may also be a performance benefit to having accesses evenly distributed
across both controllers.
First, pull two of the SATA drives (sdb and sdd) out of the datavg VG:
# modprobe dm-mirror
# pvmove /dev/sdb1 /dev/sda1
# pvmove /dev/sdd1 /dev/sdc1
# vgreduce datavg /dev/sdb1 /dev/sdd1
# pvremove /dev/sdb1 /dev/sdd1
Then, change the partition type on these two drives, using filesystem type fd (Linux raid autodetect):
Device Boot Start End Blocks Id System
/dev/sdb1 1 30515 245111706 fd Linux raid autodetect
Now, build the RAID 1 mirrors, telling md that the "other half" of the mirrors are missing (because
they're not ready to be added to the RAID yet):
# mdadm --create /dev/md0 -a -l 1 -n 2 /dev/sdd1 missing
# mdadm --create /dev/md1 -a -l 1 -n 2 /dev/sdb1 missing
Add these broken mirrors to the LVM:
# pvcreate /dev/md0 /dev/md1
# vgextend datavg /dev/md0 /dev/md1
Next, migrate off of the raw disks onto the broken mirrors:
# pvmove /dev/sda1 /dev/md0
# pvmove /dev/sdc1 /dev/md1
5