LFCS 85 🐧 LVM — Logical Volumes - KandZ

⏱️ Estimated read: 12 min | |

A Logical Volume is the block device that the filesystem sees. It is allocated from the Volume Group’s pool of Physical Extents, and it is the layer where the administrator’s capacity decisions become a mountable device. The LV is not a partition; it has no fixed position on a disk, and its extents can be mapped across multiple Physical Volumes. This is the layer that makes LVM’s resize and spanning capabilities visible to the application.

This chapter covers the Logical Volume layer: creating, inspecting, extending, reducing, and removing an LV. It assumes the PV and VG operations from the previous chapters and focuses on the commands and failure modes that the LFCS exam tests: how to create an LV with a specific size, how to grow it while mounted, how to shrink it safely, and how to remove it without leaving the VG inconsistent.

Key point: lvextend and lvreduce change the block device’s size. They do not change the filesystem’s size. The filesystem must be resized separately, and the order matters: grow the LV first, then grow the filesystem; shrink the filesystem first, then shrink the LV.

Why the Logical Volume layer exists

The block device abstraction. The LV is a block device with a name and a device path. It looks like a partition to the filesystem, but it is not tied to a physical location. The LVM layer translates the LV’s logical block addresses into Physical Extents on the VG’s PVs, and the translation is what allows the LV to span disks and be resized .

The allocation unit. An LV is allocated in Logical Extents (LEs), and each LE maps to exactly one Physical Extent (PE) on the VG’s PVs. The LE size equals the PE size, which is set at VG creation. The LV’s size is the number of LEs multiplied by the PE size, and the lvcreate command rounds up to the extent boundary.

The resize boundary. The lvextend and lvreduce commands operate on the LV’s extent mapping. They add or remove LEs from the mapping table, but they do not touch the data inside those extents. The filesystem on the LV still believes it has the old size until the filesystem resize command runs . This separation is the source of the most common LVM mistake: shrinking the LV without shrinking the filesystem first destroys data.

The filesystem dependency. The LV is useful only because a filesystem can be created on it. The filesystem’s ability to grow or shrink online determines what the LV can do. ext4 can grow online and shrink offline. XFS can grow online but cannot shrink at all. Btrfs can do both online. The LV layer is filesystem-agnostic, but the operational workflow is not.

a. Creating and inspecting Logical Volumes

lvcreate allocates extents from a VG and creates the LV. The -n option sets the name, the -L option sets the size in human-readable units, and the -l option sets the size in extents. The VG name is the last argument, and it tells lvcreate which pool to allocate from .

# Create a 5 GB LV named lv_app in the vg_data VG.
sudo lvcreate -n lv_app -L 5G vg_data

# Create an LV using a percentage of the VG's free space.
sudo lvcreate -n lv_data -l 50%FREE vg_data

# Create an LV with a specific number of extents.
sudo lvcreate -n lv_logs -l 256 vg_data

lvs provides a compact report of all LVs. The columns show the LV name, the VG, the attributes, the size, and the allocation policy.

# Compact report of all Logical Volumes.
sudo lvs

# Example output:
#   LV     VG      Attr       LSize  Pool Origin Data%
#   lv_app vg_data -wi-a-----  5.00g

lvdisplay provides the detailed view. It shows the LV’s UUID, size, number of LEs, the mapping of LEs to PEs, and the device path. The -m flag displays the mapping of logical extents to PVs and physical extents .

# Detailed attributes of a specific Logical Volume.
sudo lvdisplay /dev/vg_data/lv_app

# Display the extent mapping.
sudo lvdisplay -m /dev/vg_data/lv_app

The LV device path is /dev/vg_name/lv_name or /dev/mapper/vg_name-lv_name. Both paths point to the same device, and the filesystem commands accept either.

b. Extending and reducing Logical Volumes

lvextend adds extents to an LV. The -L option takes an absolute size or a relative size with a + prefix. The -l option takes extents or a percentage. The VG must have free extents, or the command fails .

# Extend the LV by 2 GB.
sudo lvextend -L +2G /dev/vg_data/lv_app

# Extend the LV to a total of 10 GB.
sudo lvextend -L 10G /dev/vg_data/lv_app

# Extend the LV to use all remaining free space in the VG.
sudo lvextend -l +100%FREE /dev/vg_data/lv_app

After the LV is extended, the filesystem must be grown to use the new space. The command depends on the filesystem:

# ext4: grow online.
sudo resize2fs /dev/vg_data/lv_app

# XFS: grow online (mounted).
sudo xfs_growfs /mnt/app

# Btrfs: grow online (mounted).
sudo btrfs filesystem resize max /mnt/app

lvreduce removes extents from an LV. The command is dangerous because it does not know whether the filesystem is using the extents being removed. The safe sequence is to shrink the filesystem first, then reduce the LV .

# Shrink the filesystem first (ext4 must be unmounted).
sudo umount /mnt/app
sudo resize2fs /dev/vg_data/lv_app 3G

# Then reduce the LV to the same size.
sudo lvreduce -L 3G /dev/vg_data/lv_app

XFS cannot shrink. An XFS LV is grow-only, and the only way to reduce it is to back up, recreate, and restore. Btrfs can shrink online with btrfs filesystem resize -size /mnt.

c. Removing and renaming Logical Volumes

lvremove deletes the LV and returns its extents to the VG’s free pool. The command requires the LV to be inactive (unmounted). The -f flag skips the confirmation prompt .

# Remove an LV. The filesystem must be unmounted.
sudo umount /mnt/app
sudo lvremove /dev/vg_data/lv_app

# Remove without confirmation.
sudo lvremove -f /dev/vg_data/lv_app

lvrename changes the LV’s name. The device path changes accordingly, and any fstab entry or application configuration that references the old path must be updated.

# Rename the LV from lv_app to lv_application.
sudo lvrename vg_data lv_app lv_application

lvchange modifies the LV’s attributes. The -a y and -a n options activate and deactivate the LV. The -p rw and -p ro options set the permission to read-write or read-only.

# Activate the LV.
sudo lvchange -a y /dev/vg_data/lv_app

# Set the LV to read-only.
sudo lvchange -p rw /dev/vg_data/lv_app

Complete Example Session

# ============================================
# PART 1: THE STARTING STATE
# ============================================
# The VG has free extents available for allocation.

sudo vgs vg_data

# ============================================
# PART 2: CREATE THE LV
# ============================================
# Allocate 5 GB from the VG pool.

sudo lvcreate -n lv_app -L 5G vg_data

# ============================================
# PART 3: VERIFY WITH lvs
# ============================================
# The LV is listed with its size.

sudo lvs vg_data

# ============================================
# PART 4: VERIFY WITH lvdisplay
# ============================================
# Detailed attributes and extent mapping.

sudo lvdisplay -m /dev/vg_data/lv_app

# ============================================
# PART 5: CREATE THE FILESYSTEM
# ============================================
# The LV is used like a partition.

sudo mkfs.ext4 /dev/vg_data/lv_app
sudo mkdir -p /mnt/app
sudo mount /dev/vg_data/lv_app /mnt/app

# ============================================
# PART 6: EXTEND THE LV
# ============================================
# Add 2 GB of extents to the LV.

sudo lvextend -L +2G /dev/vg_data/lv_app

# ============================================
# PART 7: GROW THE FILESYSTEM
# ============================================
# The filesystem must be told about the new space.

sudo resize2fs /dev/vg_data/lv_app
df -hT /mnt/app

# ============================================
# PART 8: SHRINK THE LV (EXT4 ONLY)
# ============================================
# Shrink the filesystem first, then the LV.

sudo umount /mnt/app
sudo resize2fs /dev/vg_data/lv_app 4G
sudo lvreduce -L 4G /dev/vg_data/lv_app

# ============================================
# PART 9: REMOVE THE LV
# ============================================
# Unmount, then remove. The extents return to the VG.

sudo lvremove /dev/vg_data/lv_app

# ============================================
# PART 10: THE FULL PICTURE
# ============================================
# lvcreate allocates.
# lvextend adds extents.
# lvreduce removes extents (after filesystem shrink).
# lvremove returns extents to the VG.
# The filesystem resize is a separate step.

echo "LV workflow complete."

The ten parts walk through the full lifecycle: create, inspect, format, extend, grow the filesystem, shrink, remove. The sequence is the same for any LV; the filesystem resize commands differ by filesystem type.

Quick Reference

LV Commands

Command	Purpose
`lvcreate`	Allocate an LV from a VG
`lvs`	Compact report of all LVs
`lvdisplay`	Detailed attributes and mapping
`lvextend`	Add extents to an LV
`lvreduce`	Remove extents from an LV
`lvremove`	Delete an LV, return extents
`lvrename`	Rename an LV
`lvchange`	Activate, deactivate, set permissions

Size Options

Option	Meaning
`-L 5G`	Absolute size
`-L +2G`	Relative size (add 2 GB)
`-l 50%FREE`	Percentage of VG free space
`-l +100%FREE`	All remaining free space

Filesystem Resize Commands

Filesystem	Grow	Shrink	Mounted?
ext4	`resize2fs`	`resize2fs`	Grow online, shrink offline
XFS	`xfs_growfs`	Not supported	Grow online
Btrfs	`btrfs filesystem resize max`	`btrfs filesystem resize -size`	Either online

Resize Order

Operation	Step 1	Step 2
Grow	`lvextend`	`resize2fs` / `xfs_growfs`
Shrink	`resize2fs` (unmounted)	`lvreduce`

Best Practices

✅ Do This:

# Create the LV with a descriptive name.
sudo lvcreate -n lv_app -L 5G vg_data                              // ✅

# Verify with lvs and lvdisplay after creation.
sudo lvs vg_data                                                    // ✅

# Extend the LV, then grow the filesystem.
sudo lvextend -L +2G /dev/vg_data/lv_app
sudo resize2fs /dev/vg_data/lv_app                                  // ✅

# Shrink the filesystem first, then the LV.
sudo resize2fs /dev/vg_data/lv_app 4G
sudo lvreduce -L 4G /dev/vg_data/lv_app                             // ✅

# Unmount before lvremove.
sudo umount /mnt/app && sudo lvremove /dev/vg_data/lv_app            // ✅

❌ Don’t Do This:

# Don't shrink the LV before the filesystem.
sudo lvreduce -L 3G /dev/vg_data/lv_app  # data loss risk          // ❌

# Don't try to shrink XFS.
# XFS is grow-only.                                                // ❌

# Don't lvremove a mounted LV.
sudo lvremove /dev/vg_data/lv_app  # fails or corrupts             // ❌

# Don't forget the filesystem resize after lvextend.
sudo lvextend -L +2G /dev/vg_data/lv_app  # filesystem unchanged  // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
LV grown but filesystem unchanged	`lvextend` only changes the block device	Run `resize2fs` / `xfs_growfs`
Data loss on shrink	`lvreduce` ran before filesystem shrink	Shrink filesystem first
`lvextend` fails	VG has no free extents	`vgextend` with a new PV
`lvremove` fails	LV is mounted	`umount` first
XFS shrink impossible	XFS does not support shrinking	Back up, recreate, restore

Real-World Examples

1. Create LV

sudo lvcreate -n lv_app -L 5G vg_data

2. Compact Report

sudo lvs

3. Detailed Report

sudo lvdisplay /dev/vg_data/lv_app

4. Extent Mapping

sudo lvdisplay -m /dev/vg_data/lv_app

5. Extend LV

sudo lvextend -L +2G /dev/vg_data/lv_app

6. Grow ext4

sudo resize2fs /dev/vg_data/lv_app

7. Grow XFS

sudo xfs_growfs /mnt/app

8. Shrink ext4

sudo resize2fs /dev/vg_data/lv_app 4G

9. Remove LV

sudo lvremove /dev/vg_data/lv_app

10. Rename LV

sudo lvrename vg_data lv_app lv_new

Visual

The LV in the LVM Stack

┌─────────────────────────────────────────────────────────┐
│  FILESYSTEM (ext4, XFS, Btrfs)                          │
│  /mnt/app                                               │
│         │                                               │
│         ▼                                               │
│  LOGICAL VOLUME                                         │
│  /dev/vg_data/lv_app                                    │
│  ┌───────────────────────────────────────────────────┐  │
│  │  LE 0  │  LE 1  │  LE 2  │  ...  │  LE n          │  │
│  └────┬───┴────┬───┴────┬───┴───────┴────┬───────────┘  │
│       │        │        │                │              │
│       ▼        ▼        ▼                ▼              │
│  VOLUME GROUP vg_data                                   │
│  (pool of Physical Extents)                             │
│         │                                               │
│         ▼                                               │
│  PHYSICAL VOLUMES                                       │
│  /dev/sdc, /dev/sdd                                     │
└─────────────────────────────────────────────────────────┘

The Resize Order

┌─────────────────────────────────────────────────────────┐
│  GROW                                                   │
│  1. lvextend -L +2G /dev/vg_data/lv_app                 │
│     → LV mapping gains 2 GB of extents                  │
│  2. resize2fs /dev/vg_data/lv_app                       │
│     → filesystem uses the new space                     │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  SHRINK                                                 │
│  1. umount /mnt/app                                     │
│  2. resize2fs /dev/vg_data/lv_app 3G                    │
│     → filesystem shrinks to 3 GB                        │
│  3. lvreduce -L 3G /dev/vg_data/lv_app                  │
│     → LV mapping removes the extents                    │
│                                                         │
│  Wrong order on shrink = data loss.                     │
└─────────────────────────────────────────────────────────┘

The Extent Mapping

┌─────────────────────────────────────────────────────────┐
│  lvdisplay -m /dev/vg_data/lv_app                       │
│                                                         │
│  LV: lv_app                                             │
│  LE 0    → PV /dev/sdc, PE 0                            │
│  LE 1    → PV /dev/sdc, PE 1                            │
│  ...                                                    │
│  LE 639  → PV /dev/sdc, PE 639                          │
│  LE 640  → PV /dev/sdd, PE 0    ← spans to second disk  │
│  ...                                                    │
│                                                         │
│  The application sees a single block device.            │
└─────────────────────────────────────────────────────────┘

The Filesystem Dependency

┌─────────────────────────────────────────────────────────┐
│  LV OPERATION     ext4        XFS         Btrfs         │
│  ─────────────────────────────────────────────────────  │
│  Grow online      resize2fs   xfs_growfs  btrfs resize  │
│  Shrink online    no          no          btrfs resize  │
│  Shrink offline   resize2fs   no          btrfs resize  │
│                                                         │
│  XFS is grow-only. The LV is grow-only for XFS.         │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
Purpose	Block device allocated from a VG
Create	`lvcreate -n name -L size vg_name`
Compact report	`lvs`
Detailed report	`lvdisplay`
Extent mapping	`lvdisplay -m`
Extend	`lvextend -L +size /dev/vg/lv`
Reduce	`lvreduce -L size /dev/vg/lv`
Remove	`lvremove /dev/vg/lv`
Rename	`lvrename vg old new`
Device path	`/dev/vg_name/lv_name`

Key takeaways:

The LV is the block device the filesystem sees. It is allocated from the VG’s pool of extents and can span multiple PVs. The device path is /dev/vg_name/lv_name .
lvcreate allocates extents. The -L option sets the size, the -l option sets the extent count or percentage, and the VG name tells the command which pool to use.
lvextend and lvreduce change the block device, not the filesystem. The filesystem must be resized separately with resize2fs, xfs_growfs, or btrfs filesystem resize .
The resize order is asymmetric. Grow the LV first, then the filesystem. Shrink the filesystem first, then the LV. The wrong order on shrink destroys data.
XFS is grow-only. An XFS LV cannot be shrunk. The only way to reduce it is to back up, recreate, and restore.
lvremove requires the LV to be unmounted. The extents return to the VG’s free pool, and they can be allocated to another LV.

Remember: The Logical Volume is the layer where the administrator’s capacity decisions become a device that the filesystem can use. The lvcreate command allocates the extents, the lvextend and lvreduce commands change the allocation, and the filesystem resize commands make the new size visible to the application. The LV layer is simple; the discipline is the order. Grow the LV before the filesystem, shrink the filesystem before the LV, and never assume that the filesystem knows about a size change that the LV has not been told about.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!