Diagnosing the Discrepancy
The first step in troubleshooting is to understand where the mismatch originates. Often, users notice that df -h reports a certain total size, while lsblk or lvs shows a different capacity for the same device. This inconsistency typically arises when a logical volume has been extended at the LVM layer but the filesystem residing on it has not yet been grown to match.
Begin by checking the current status of your logical volumes. Use the command lvs -o+data_percent,lv_size,vg_name to get a detailed view of your volumes. Look for any logical volumes where the reported size does not align with the expected allocation based on your volume group’s free space. Additionally, run vgs to see if there is unallocated space in the volume group that should have been assigned to your logical volume. If the volume group shows significant free space, it confirms that the logical volume was not properly expanded during a previous operation.
Another common cause is a stale cache or metadata issue. While less frequent, running pvs can help verify that the physical volumes are recognized correctly by the system. Ensure that the physical extents are marked as allocated and not reserved for other purposes. If the physical volumes look healthy, focus your attention on the logical volume configuration.
Synchronizing Logical Volume and Filesystem
Once you have identified that the logical volume needs to be resized, you must perform two distinct actions: extend the logical volume and then grow the filesystem. Skipping either step will result in the discrepancy you are experiencing. The order matters because extending the filesystem without extending the logical volume first will fail, as there is no new space to allocate.
To extend the logical volume, use the lvextend command. For example, if you want to increase the size of /dev/mapper/vg0-lv0 by 10 gigabytes, you would run:
lvextend -L +10G /dev/mapper/vg0-lv0If you wish to consume all remaining free space in the volume group, you can use the +100%FREE flag instead of specifying an exact size. This ensures that no space is left unused within the volume group boundaries. After executing this command, verify the change with lvs to confirm that the logical volume size has increased.
However, the filesystem still believes it only occupies the original size. You must now grow the filesystem to utilize the newly added extents. The command depends on the filesystem type. For ext4 and ext3, use resize2fs:
resize2fs /dev/mapper/vg0-lv0For XFS, which cannot be shrunk and requires a different tool, use xfs_growfs. Note that XFS requires the mount point path rather than the device path:
xfs_growfs /mount/pointAfter resizing, check df -h again. The "Size" column should now reflect the new total, and the "Available" space should have increased accordingly. The "Used" space remains unchanged unless you have filled the new capacity.
Handling Thin Provisioning Issues
If you are using thin provisioned logical volumes, the behavior differs slightly. Thin pools allocate space dynamically, so the apparent size might be much larger than the actual data written. In such cases, discrepancies often relate to the pool's metadata or overcommitment ratios rather than simple extension errors.
Check the thin pool usage with lvs -o+pool_lv,data_percent,metadata_percent. If the data percentage is high, you may need to add more physical volumes to the pool. Refer to our guide on Creating an LV Thin Pool with Prioritization of Two PVs for strategies on managing storage tiers and ensuring efficient allocation in complex setups. This is particularly relevant if you are dealing with mixed-speed storage devices and need to balance performance with capacity.
Preventing Future Allocation Errors
To avoid these issues in the future, adopt a consistent workflow for storage management. Always verify the output of df and lsblk after major storage changes. Implement monitoring alerts that trigger when filesystem usage exceeds specific thresholds, giving you time to expand volumes before they fill up.
Additionally, document your volume group layouts and reserve a small amount of free space in each volume group for emergency expansions. This practice prevents situations where you must immediately add new physical disks to resolve a simple sizing error. Regular audits of your LVM structure using vgck can also catch metadata inconsistencies early, ensuring that your storage infrastructure remains reliable and accurately represented.
Frequently Asked Questions
Why does df show less space than lvs?
This occurs when the logical volume has been extended but the filesystem has not been resized to match. The operating system kernel only sees the filesystem boundary, not the underlying block device expansion. You must run the appropriate filesystem growth command to bridge this gap.
Can I shrink an LVM logical volume?
Shrinking is risky and generally unsupported for most filesystems like XFS. For ext4, you can shrink both the filesystem and the logical volume, but you must unmount the filesystem first and ensure the data fits within the smaller size. Always backup critical data before attempting to reduce volume sizes.
What causes "No space left on device" despite low usage?
This error often indicates that inode exhaustion has occurred rather than block space exhaustion. Check inode usage with df -i. If inodes are full, you may need to recreate the filesystem with more inodes or delete many small files to free up the metadata structures.
How do I fix a corrupted LVM metadata?
If LVM commands fail or report errors, try restoring metadata from backups using vgrestore or pvcreate --restorefile. In severe cases, you may need to re-import the volume group with vgimport. Always keep regular backups of your LVM metadata to facilitate quick recovery.
Is it safe to resize a mounted filesystem?
Yes, both ext4 and XFS support online resizing. However, it is best practice to minimize write activity during the operation to prevent potential corruption. For ext4, resize2fs works on mounted volumes. For XFS, xfs_growfs also operates on mounted filesystems, provided you are expanding, not shrinking.