3.2 LVM & Standard Mount Point Allocation (102.1)

3.2 LVM & Standard Mount Point Allocation (102.1)

Quick Summary: The Logical Volume Manager (LVM2) provides flexible, abstracted storage management that eliminates the rigid constraints of traditional disk partitioning. By aggregating raw block devices (Physical Volumes) into storage pools (Volume Groups) divided into Physical Extents (PEs), administrators can allocate dynamic Logical Volumes (LVs) that can be resized online, spanned across multiple disks, and snapshotted for zero-downtime backups.

---

1. Logical Volume Manager (LVM2) Architecture

Traditional disk partitioning forces filesystems into fixed, contiguous sector ranges on a specific physical drive. When a static partition runs out of space, resizing requires unmounting, repartitioning, and potential downtime. LVM decouples filesystems from physical hardware by introducing a modular three-tier abstraction layer.

  Physical Disks:       [ /dev/sdb1 ] (100GB)         [ /dev/sdc1 ] (100GB)
                              │                             │
                              ▼                             ▼
  Physical Volumes (PV): [ PV: /dev/sdb1 ]            [ PV: /dev/sdc1 ]
                              └──────────────┬──────────────┘
                                             ▼
  Volume Group (VG):          [ Volume Group: vg_data (200GB) ]
                              [ Divided into 4 MiB Physical Extents (PE) ]
                                    ┌────────┴────────┐
                                    ▼                 ▼
  Logical Volumes (LV):       [ lv_var (50GB) ]   [ lv_home (150GB) ]
                                    │                 │
  Filesystems & Mounts:       [ ext4: /var ]      [ XFS: /home ]

The Core LVM Components

1. Physical Volume (PV): Raw block devices—such as entire hard drives (/dev/sdb), disk partitions with type code 8e (MBR) or 8e00 (GPT) (/dev/sdb1), or software RAID arrays (/dev/md0)—initialized with an LVM label and metadata area.
2. Volume Group (VG): A unified storage pool created by combining one or more PVs. The total capacity of a VG is the sum of its constituent PVs.
3. Physical Extent (PE): The smallest unit of storage allocation inside a Volume Group. By default, each PE is 4 MiB, though custom sizes (e.g., 8 MiB, 16 MiB, 32 MiB) can be defined during VG creation with vgcreate -s.
4. Logical Extent (LE): The allocation unit of a Logical Volume. An LV is composed of an ordered sequence of LEs, each mapping directly (1:1) to a specific Physical Extent within the VG.
5. Logical Volume (LV): A virtual block device carved out of a Volume Group. To the operating system and applications, an LV behaves exactly like a standard physical disk partition (e.g., /dev/vg_data/lv_app or /dev/mapper/vg_data-lv_app), which can be formatted with any filesystem and mounted.

---

2. Advantages of LVM Storage Allocation

• Dynamic Online Resizing: Filesystems on logical volumes can be expanded on the fly while actively mounted and servicing production I/O.
• Storage Pooling across Disks: A Volume Group can span dozens of separate physical disks, allowing a single 50 TB filesystem to exist seamlessly across multiple smaller drives.
• Point-in-Time Snapshots: LVM snapshots implement Copy-on-Write (CoW) to capture a frozen state of an LV for consistent backups or testing without halting applications.
• Data Migration (pvmove): Storage administrators can migrate active data from an aging or failing physical disk to a new drive without taking filesystems offline.
• Striping and Mirroring: LVM supports I/O striping (RAID 0) across multiple PVs for high throughput, or mirroring (RAID 1) for block-level redundancy.

---

3. LVM Administration Command Matrix

LVM management utilities follow a strict, intuitive naming hierarchy based on the target layer: pv* for Physical Volumes, vg* for Volume Groups, and lv* for Logical Volumes.

---

4. End-to-End LVM Deployment & Lifecycle Workflow

Step 1: Initializing Physical Volumes

# Initialize raw partitions as LVM Physical Volumes
sudo pvcreate /dev/sdb1 /dev/sdc1

# Inspect PV metadata and allocation status
sudo pvs
sudo pvdisplay /dev/sdb1

  PV         VG        Fmt  Attr PSize   PFree 
  /dev/sdb1            lvm2 ---  100.00g 100.00g
  /dev/sdc1            lvm2 ---  100.00g 100.00g

Step 2: Creating and Expanding Volume Groups

# Create a VG named vg_storage using /dev/sdb1 with default 4 MiB PE size
sudo vgcreate vg_storage /dev/sdb1

# Alternatively, specify a custom PE size of 16 MiB
sudo vgcreate -s 16M vg_storage /dev/sdb1

# Extend the Volume Group by adding a second physical drive
sudo vgextend vg_storage /dev/sdc1

# View Volume Group summary
sudo vgs

  VG         #PV #LV #SN Attr   VSize   VFree  
  vg_storage   2   0   0 wz--n- 199.99g 199.99g

Step 3: Creating Logical Volumes

# Create a 40 GiB LV using absolute size flag (-L)
sudo lvcreate -L 40G -n lv_data vg_storage

# Create an LV using extent count flag (-l) using 100% of remaining free space
sudo lvcreate -l 100%FREE -n lv_backup vg_storage

# Create an LV specifying exact number of Physical Extents (e.g., 2500 PEs * 4 MiB = 10 GiB)
sudo lvcreate -l 2500 -n lv_web vg_storage

💡 LPIC-1 Exam Fill-in-the-Blank Alert: Note the difference between -L and -l in lvcreate and lvextend:

• -L (uppercase): Specifies capacity in human-readable byte units (e.g., -L 50G, -L +10G, -L 500M).
• -l (lowercase): Specifies capacity in extent counts or percentage keywords (e.g., -l 1250, -l +100%FREE, -l 50%VG).

---

5. Filesystem Resizing Integration: ext4 vs. XFS

Resizing a logical volume is a two-step operation: resizing the block device container (LV) and resizing the filesystem residing inside that container. Modern LVM provides the -r (or --resizefs) flag to execute both steps in a single atomic command.

Expanding ext4 and XFS Volumes Online

# Method 1 (Recommended): Single command with automatic filesystem expansion
sudo lvextend -L +20G -r /dev/vg_storage/lv_data

# Method 2: Manual two-step process for ext4
sudo lvextend -L +20G /dev/vg_storage/lv_data
sudo resize2fs /dev/vg_storage/lv_data

# Method 2: Manual two-step process for XFS (Note: targets mountpoint!)
sudo lvextend -L +20G /dev/vg_storage/lv_data
sudo xfs_growfs /mnt/data

Resizing Differences: ext4 vs. XFS

⚠️ LPIC-1 Trap: Attempting to run xfs_growfs /dev/vg_storage/lv_data on an unmounted device will fail. xfs_growfs requires the mount point directory as its argument. Furthermore, never attempt to reduce an LV holding an XFS filesystem with lvreduce—it will permanently corrupt the filesystem!

Step-by-Step ext4 Filesystem Reduction Workflow

Because shrinking carries risk of data truncation, ext4 filesystems must be shrunk before reducing the logical volume:

# 1. Unmount the filesystem
sudo umount /mnt/data

# 2. Force an integrity check (mandatory before resize2fs reduction)
sudo e2fsck -f /dev/vg_storage/lv_data

# 3. Shrink the ext4 filesystem FIRST to target size (e.g., 25 GiB)
sudo resize2fs /dev/vg_storage/lv_data 25G

# 4. Reduce the Logical Volume to match the filesystem size
sudo lvreduce -L 25G /dev/vg_storage/lv_data

# 5. Remount the filesystem
sudo mount /dev/vg_storage/lv_data /mnt/data