On a Linux host using LVM, you run `lvextend -L +50G /dev/vg0/data` and it reports success, yet `df -h` still shows the old size for the mounted filesystem. Why, and what do you run to make the filesystem use the new space?

## Two layers, two independent sizes LVM inserts a layer between the disk and the filesystem. Physical volumes (whole disks or partitions) are pooled into a volume group, the volume group is carved into logical volumes, and a filesystem is created on a logical volume. Each layer tracks its own size: - The logical volume's size is stored in LVM metadata, as a count of physical extents. - The filesystem's size is stored in its own superblock, in filesystem blocks. Growing one does not grow the other. That is the whole of the surprise: `lvextend` is a block-layer operation, and `df` is a filesystem-layer report. ## What lvextend actually did `lvextend -L +50G /dev/vg0/data` took 50 GB worth of free extents from the volume group and mapped them onto the end of the logical volume. The device-mapper table for the device is updated live, so the block device is larger the moment the command returns — no unmount, no reboot. You can confirm at the block layer: ``` lvs -o lv_name,lv_size vg0 lsblk /dev/vg0/data ``` Both show the new size while `df -h /data` still shows the old one. That discrepancy is the diagnostic: block layer big, filesystem layer small. ## Growing the filesystem The tool depends on the filesystem, and it is worth memorising which argument each one takes: ``` resize2fs /dev/vg0/data # ext2/ext3/ext4 - takes the DEVICE, online grow is supported xfs_growfs /data # XFS - takes the MOUNT POINT, must be mounted ``` With no size argument, both grow to fill whatever the underlying device now is, which is exactly what you want after an `lvextend`. Online growth is normal on both: ext4 supports online resize through a kernel ioctl, and XFS can only be grown while mounted, so there is no reason to take an outage for a grow. ## Doing both in one command `lvextend -r -L +50G /dev/vg0/data` (long form `--resizefs`) extends the logical volume and then calls `fsadm`, a helper shipped with LVM2 that detects the filesystem type and invokes the matching resize tool. `lvresize -r` behaves the same way. If `fsadm` does not recognise the filesystem it refuses, and you are left in exactly the state described in the question — a grown LV with an unchanged filesystem, which is harmless and fixable by hand. ## The -L versus -l trap `lvextend` accepts sizes two ways, and both accept absolute or relative forms: - `-L 100G` sets the size **to** 100 GB; `-L +100G` **adds** 100 GB. - `-l 100` sets the size to 100 extents; `-l +100%FREE` adds every free extent in the volume group. Typing `-L 100G` when you meant `-L +100G` on a volume that is already larger is the classic slip. `lvextend` itself will not reduce a volume — it errors out rather than shrinking — but `lvresize` will happily do what you asked, and shrinking a block device out from under a live filesystem destroys data. Prefer the explicit `+` form for growth. ## When there is nothing to extend with If the volume group has no unallocated extents, `lvextend` fails with an insufficient-free-extents error instead of succeeding. Check with `vgs`, whose `VFree` column is the free space in the group. Getting more space into the group is a separate step: adding a new physical volume with `vgextend`, or telling LVM that an existing physical volume's underlying device has grown with `pvresize`. ## Verifying the whole chain After a successful grow, all four views should agree: ``` vgs # VFree - what is left in the group lvs -o lv_name,lv_size # the logical volume size lsblk # the block device the kernel sees df -h /data # what the filesystem now offers ``` If `df` is the only one lagging, you skipped the filesystem step. If `lsblk` lags too, the block device itself never grew and the problem is below LVM — a virtual disk that was enlarged in the hypervisor but never rescanned, for instance. ## Why this design is deliberate The separation is a feature, not an oversight. A logical volume may hold something that is not a filesystem at all — a database's raw device, a swap area, an encrypted container — and LVM has no business guessing how to resize an arbitrary payload. Keeping the layers independent is what lets the same `lvextend` serve all of them, with `-r` as the convenience path for the common case.