Table of Contents
Introduction
Logical volumes provide a flexible way to manage disk space that goes far beyond traditional fixed partitions. In Linux, this is normally implemented through the Logical Volume Manager, or LVM. Instead of thinking in terms of “this physical disk has this one partition with a fixed size,” you gain an extra abstraction layer. You work with volume groups and logical volumes that can grow, shrink, and move across physical devices with much less disruption to your system.
In this chapter you will focus specifically on logical volumes as LVM presents them. Other LVM building blocks and broader storage topics are handled elsewhere, so here you will stay at the level of what a logical volume is, how it behaves, and what is uniquely possible with it.
A logical volume is a virtual block device that sits on top of a pool of storage and can be resized or moved without directly manipulating the underlying physical disk layout.
Logical Volumes as Virtual Block Devices
A logical volume behaves like a regular block device from the point of view of the rest of the system. It shows up under /dev with a name derived from its volume group and its own logical name. For example, if you have a volume group called vgdata and a logical volume called lvbackup, you will typically see a device file /dev/vgdata/lvbackup. You can format this device with a filesystem like EXT4 or XFS, mount it, and use it exactly like a normal partition such as /dev/sda1.
The key difference is that the logical volume is not tied to a single fixed region on one disk. Instead, it maps to a set of allocation units inside a volume group. LVM internally translates reads and writes on the logical volume into operations on those underlying units, so the logical volume can grow into additional free space in the volume group without any change to its apparent identity or device file path.
From the user perspective, the logical volume is just where you put the filesystem or other data. The volume group behind it and the physical storage below that are hidden behind the abstraction. This separation frees you from having to plan every partition size in advance because you can adjust logical volumes later.
Naming and Identification
Logical volumes are organized by volume group. A volume group is a named pool, for instance vgroot or vgdata. Inside that volume group, each logical volume has its own name, such as root, home, or db. Together they form a path-like pair: vgname/lvname.
The device names under /dev reflect this structure. You typically have a directory named after the volume group, for example /dev/vgroot, containing device files for each logical volume, such as /dev/vgroot/root and /dev/vgroot/home. There is also a generic mapping under /dev/mapper, often with an underscore encoded representation of the names. Tools and scripts usually prefer the /dev/vgname/lvname names because they are easier to read.
A logical volume also has a unique identifier at the LVM metadata level. This is not usually needed for daily work but is important for LVM itself. For normal administration tasks you mostly care about the human friendly vgname/lvname pair and the corresponding device file path.
Size and Allocation Units
Logical volumes are allocated in chunks known as physical extents within their volume group. A physical extent is a fixed-size block of space in the group. The size of a physical extent is set when the volume group is created. Common sizes are 4 MiB or 8 MiB, but other values are possible. The size of a logical volume is always a multiple of the extent size.
If a volume group has a physical extent size of $4 \,\text{MiB}$ and a logical volume is defined with $1000$ extents, then its size is:
$$
\text{LV size} = \text{extent size} \times \text{number of extents} = 4\,\text{MiB} \times 1000 = 4000\,\text{MiB}
$$
which is roughly $3.9\,\text{GiB}$.
You normally specify logical volume sizes in human units such as 10G or 500M, and LVM converts that to an integral number of extents. This extent-based allocation is what makes it possible to grow or shrink volumes. LVM simply changes how many extents are mapped to the logical volume, as long as there is free space in the volume group.
The size of a logical volume is always an integer multiple of the volume group’s physical extent size.
Basic Operations on Logical Volumes
Logical volumes support several fundamental operations that are unique compared to fixed partitions. You can create them from free space inside a volume group, extend them when extra space is needed, and remove them when they are no longer required. These operations modify the mapping between the logical volume and the extents in the volume group but do not require you to repartition disks.
Creating a logical volume assigns it an initial size and name within a volume group. After that, you treat it like a normal block device by creating a filesystem or other data structure on top of it. Extending a logical volume increases the number of extents that belong to that volume within the group. As long as there are unallocated extents available in the volume group, the volume can grow without any change to the underlying partition layout.
Shrinking a logical volume is more delicate. In logical terms, it is just a reduction of the number of extents mapped to the volume. In practice, if there is a filesystem on the volume, you must first ensure the filesystem itself is reduced safely before the logical size is reduced. If the logical volume is made smaller than the filesystem it contains, data will be lost or corrupted. Shrinking is possible, but requires careful coordination with the filesystem layer above the logical device.
Removing a logical volume frees its extents in the volume group. Once removed, the device file disappears and any data on that volume becomes inaccessible. It is important to unmount the filesystem and confirm that no processes are still using the volume before deleting it.
Resizing Logical Volumes Safely
The ability to adjust the size of logical volumes is one of the strongest advantages of using them, but it also introduces some safety considerations. Extending a logical volume is relatively straightforward if it hosts a modern filesystem that supports online growth. Shrinking requires more preparation.
When you extend a logical volume, its size in extents increases. To make use of the new space, the filesystem on the volume must also be grown. Many filesystems support online resize upwards, which means you can perform the filesystem grow operation while it is mounted and in use, once the logical volume size has been increased. The exact steps and tools depend on the filesystem type and are not specific to logical volumes themselves, but the key is that the logical volume and the filesystem must agree on the size.
Shrinking has the opposite order. The filesystem must be reduced first, and usually must be unmounted to do so. Only after the filesystem is successfully shrunk to a smaller size can the logical volume be reduced. If the logical volume is reduced before the filesystem, you effectively discard blocks that the filesystem still believes exist, which will likely result in unrecoverable data loss.
Always grow a filesystem after extending a logical volume, and always shrink the filesystem before reducing the logical volume size.
In addition to the logical size changes, you may sometimes want to redistribute extents so that a logical volume uses specific physical devices or avoids failing hardware. This is achieved by moving extents inside the volume group, which can be done while the logical volume remains in use. The important point is that the identity and size of the logical volume remain stable from the filesystem point of view, even though its underlying physical location changes.
Using Logical Volumes for Flexibility
Logical volumes are particularly useful wherever you want flexibility in how storage is allocated between different parts of a system. Instead of assigning fixed partitions for /, /home, /var, and other areas, you can create separate logical volumes inside one volume group and resize them as needs change.
For example, you might start with a relatively small logical volume for /home if you do not expect significant user data. If that assumption turns out to be wrong and /home fills up, you can extend the home logical volume by allocating more extents from the volume group, then grow the filesystem. This avoids re-partitioning the disk or reinstalling the operating system. Similarly, if a database volume needs more space, you can extend the logical volume that holds it, provided the volume group still has free extents or is expanded with additional physical storage.
Logical volumes also make it easier to relocate data to new hardware. If you add a new disk to the system and bring it into an existing volume group, you can move extents from old devices to the new one while keeping the same logical volume name and mount points. Once the extents are moved, the old disk can be removed with minimal downtime. Logical volumes provide a stable view of storage to the system while the actual physical layout evolves over time.
Advanced Logical Volume Types
Beyond simple linear logical volumes, which map extents sequentially, LVM supports more complex logical volume types that add features such as redundancy or snapshots. The logical volume abstraction is flexible that way. Many of these advanced functions are implemented as variations of how extents are mapped inside the volume group, but from the operating system perspective they are still just logical volumes.
One important advanced capability is the snapshot logical volume. A snapshot preserves the state of an existing logical volume at a specific point in time, while allowing the original volume to continue changing. LVM achieves this with copy on write techniques, where only changes after the snapshot are stored separately. From the user perspective, the snapshot appears as another logical volume that can be mounted and read, for example to back up a consistent view of the data. Details of snapshot management belong to broader LVM discussions, but it is useful to know that they are special types of logical volumes.
There are also logical volumes that provide striping or mirroring on top of multiple physical devices. These can improve performance or resilience. The exact configuration and trade offs involve more than just the logical volume itself and are considered in the wider context of storage design. Still, the essential point remains that logical volumes provide the interface for these capabilities. You work with them using the same logical volume names and device files, and the complexity of how data is spread across physical devices is hidden behind the abstraction.
Logical Volumes and System Integration
Logical volumes integrate cleanly with the rest of a Linux system. They can be used anywhere a normal block device could be used, such as for root filesystems, home directories, data partitions, swap space, or application-specific storage. At boot time, the init system activates the volume groups and logical volumes so their device files are available before filesystems are mounted according to /etc/fstab.
Because logical volumes are identified by volume group and logical volume name, they remain stable even if physical device names like /dev/sda or /dev/sdb change due to hardware reordering. This improves system robustness in configurations with several disks or when adding or removing devices. It is common to reference logical volumes directly in mount configuration files so that your system starts reliably regardless of low level device ordering.
When planning a system layout with logical volumes, the key design work is determining how many logical volumes you need and how much free space to leave in the volume group for future growth. You can then adjust allocations over time without reinstalling or repartitioning. Logical volumes give you this long term flexibility and help separate the logical view of your storage from the physical changes that inevitably happen as disks fill up or get replaced.