In enterprise Linux infrastructure environments governed by the Logical Volume Manager (LVM), modifying storage typologies requires strict procedural discipline. A common administrator trap occurs when a target disk shows low active utilization, creating a false impression that it can be safely dropped directly from the volume group.
This document outlines the operational mechanics of LVM block allocation and provides an engineering guide to safely evicting a physical disk (/dev/sdb) from a volume group without losing data or deleting the top-level Logical Volume (LV).
Consider an environment reporting the following structural layout:
/dev/sda3): Containing root partitions, swap space, and a partial slice of a data volume./dev/sdb): A 10GB raw disk bound to the same Volume Group./dev/mapper/ubuntu--vg-lv--data): Total capacity of 14.2GB, formatted with an ext4 filesystem, currently mounted to /data and utilizing only 2.2MB of actual file data.df -Th shows only 2.2MB of written data inside a 14G boundary, LVM has already mapped the 14.2 Gigabytes of Physical Extents (PEs) continuously across both /dev/sda3 and /dev/sdb. If an administrator forcefully removes /dev/sdb using vgreduce --force, the tail-end blocks of the logical allocation matrix vanish. This instantly destroys the metadata and block integrity of the filesystem, causing immediate file corruption or a catastrophic kernel panic during mount states.
To pull a disk out cleanly without running a block-by-block migration tool (pvmove), the filesystem boundaries must be resized inward first, ensuring that all remaining physical extents collapse neatly back into the boundaries of the primary disk (/dev/sda3).
The structural capacity to safely shrink file systems down into reduced physical spaces depends strictly on the architecture of the underlying filesystem format:
| Filesystem Type | Supports Shrinking? | Supports Growing? | Behavior with lvreduce -r |
|---|---|---|---|
| ext2 / ext3 / ext4 | Yes | Yes | Automatically executes resize2fs safely before shrinking the LV boundaries. |
| Btrfs | Yes | Yes | Requires manual filesystem minimization before reducing the logical volume blocks. |
| XFS | No | Yes | Fails explicitly. XFS is fundamentally design-restricted against downward block scaling. |
pvmove), you cannot shrink the filesystem. You must back up the data locally, completely wipe and destroy the logical volume using lvremove, drop the disk, rebuild a smaller target logical volume on the remaining disk space, and restore data from backups.
The following instructions demonstrate how to safely reduce an ext4 filesystem and logical volume to fit on the primary disk, clearing /dev/sdb entirely.
Active open file handles block underlying disk boundary modifications. Isolate the mount point:
# umount /data/
Note: If the terminal returns a "target is busy" state, isolate processes holding locks using fuser -mv /data or lsof +D /data, terminate the associated PIDs, and re-execute.
Before modifying sector maps, you must pass a clean filesystem check. Once checked, the lvreduce utility with the -r (resize) parameter ensures the underlying ext4 allocation tables scale down safely before the underlying LVM container scales down.
We will scale the volume down safely to 4G, which perfectly fits inside the remaining ~4.2G available on sda3.
# e2fsck -f /dev/mapper/ubuntu--vg-lv--data # lvreduce -r -L 4G /dev/mapper/ubuntu--vg-lv--data
Confirm the prompt action by selecting y. LVM will execute resize2fs internally, and adjust the container boundaries seamlessly.
Because the Logical Volume now completely resides within the sector boundaries of /dev/sda3, /dev/sdb is now fully unallocated. Sever its association with the volume group:
# vgreduce ubuntu-vg /dev/sdb
Clear the LVM header structural signatures on the target device to return it back to a standard raw block device state:
# pvremove /dev/sdb
Re-attach the filesystem to the standard operational mount point and run block structure checks to verify alignment:
# mount /data/ # lsblk # df -Th /data/
The target disk /dev/sdb is now completely independent and detached from LVM trees, ready to be safely reassigned, expanded, or hot-swapped entirely.