Managing storage in production environments requires precision, especially when working with LVM-backed filesystems on cloud infrastructure. This guide documents a production-safe procedure to:
- Shrink a logical volume
- Migrate data off selected physical volumes
- Remove those PVs from the volume group
- Detach the correct Azure-managed disks using LUN mapping
- Reclaim and extend remaining storage
This process ensures zero data loss and controlled disk decommissioning.
Step 1: Stop the Application
Before performing any filesystem shrink or LVM modification, stop the service using the volume.
systemctl stop cassandra.service #Taken as example
This ensures no open file handles or write operations interfere with filesystem operations.
Step 2: Shrink the Logical Volume Safely
Shrinking an LVM-backed ext4 filesystem must follow the correct sequence:
- Unmount filesystem
- Run filesystem check
- Shrink filesystem
- Shrink logical volume
umount /DATADISK
e2fsck -f /dev/vg1/DATADISK
resize2fs /dev/vg1/DATADISK 7T
lvreduce -L 7T /dev/vg1/DATADISK
mount /DATADISK
df -h
vgs
Explanation
e2fsck -fensures filesystem integrity before resizing.resize2fsreduces the ext4 filesystem size.lvreducereduces the logical volume to match the new filesystem size.vgsconfirms free extents are now available in the volume group.
Important: Always shrink the filesystem before shrinking the logical volume.
Step 3: Migrate Data from a Physical Volume
To remove a disk from LVM, all data must first be migrated off that physical volume.
Example:
pvmove /dev/sda
This relocates all extents from /dev/sda to other available PVs within vg1.
After successful migration:
vgreduce vg1 /dev/sda
pvremove /dev/sda
At this point:
- The volume group no longer references
/dev/sda - The disk is safe to detach from Azure
Step 4: Identify the Correct Azure Disk Using LUN Mapping
In Azure, disks are attached using Logical Unit Numbers (LUNs). Linux maps these to /dev/sdX devices.
To verify the mapping:
ls -l /dev/disk/azure/scsi1/
Example output:
lun0 -> ../../../sda
lun3 -> ../../../sdb
lun4 -> ../../../sdc
Interpretation
| Azure LUN | Linux Device |
|---|---|
| lun0 | /dev/sda |
| lun3 | /dev/sdb |
| lun4 | /dev/sdc |
If /dev/sda was removed from LVM, then LUN 0 is the disk that must be detached in the Azure portal.
This verification step is critical to prevent accidental detachment of active disks.
Step 5: Extend the Remaining Logical Volume
Once unwanted PVs are removed, reallocate all free extents to the primary logical volume:
lvextend -l +100%FREE /dev/vg1/DATADISK
resize2fs /dev/vg1/DATADISK
This expands the logical volume and filesystem to utilize all available space within the volume group.
Validation and Verification
After completing the procedure, validate the storage configuration:
pvs
vgs
lvs -a -o +devices
lsblk
Confirm:
- Removed devices are no longer part of the volume group
- Logical volumes reference only intended physical volumes
- Filesystem size matches expected allocation
- No unintended mounts remain
Common Mistakes to Avoid
- Shrinking logical volume before shrinking filesystem
- Running
lvreduceon a mounted filesystem - Detaching Azure disk before removing it from LVM
- Failing to verify LUN-to-device mapping
- Skipping filesystem integrity checks
Conclusion
This approach provides a controlled and production-safe method for:
- Decommissioning Azure data disks
- Rebalancing LVM storage
- Reclaiming unused capacity
- Avoiding downtime and data loss
By combining LVM best practices with Azure LUN validation, storage changes can be executed safely and predictably in enterprise environments.



