How to grow a filesystem on LVM

When an LVM logical volume grows but the mounted filesystem still shows the old size, applications can continue to fail with low-space errors even though the block device has more capacity. Growing the filesystem brings the extra logical-volume space into the mounted path where services write data.

The grow command depends on the filesystem type rather than on LVM itself. ext4 uses resize2fs against the logical-volume device, while XFS uses xfs_growfs against the mount point and must be mounted during the grow.

Start only after the logical volume already has the intended size from an earlier lvextend or lvresize step. Keep a backup or storage snapshot before changing production storage, and use the root-filesystem flow for / because boot and rescue access change the risk profile.

Related: How to increase the size of an LVM logical volume
Related: How to grow the root filesystem on LVM

Steps to grow an LVM-backed filesystem:

  1. Identify the mounted filesystem and type. 
    $ findmnt /srv/data --output TARGET,SOURCE,FSTYPE,SIZE,AVAIL
TARGET    SOURCE                  FSTYPE   SIZE  AVAIL
/srv/data /dev/mapper/vgdata-data ext4   487.2M 451.2M

    Replace /srv/data with the mount point that should receive the extra space. The SOURCE column should point to the LVM device, commonly under /dev/mapper/ or /dev/<vg>/<lv>.

  2. Confirm that the logical volume is larger than the mounted filesystem. 
    $ sudo lvs --units m --nosuffix --options lv_path,lv_size /dev/vgdata/data
  Path             LSize  
  /dev/vgdata/data 1024.00

    If the logical volume still shows the old size, extend the LV first before growing the filesystem.
    Related: How to increase the size of an LVM logical volume

  3. Confirm that a current backup or storage snapshot covers the filesystem.

    Growing ext4 and XFS is normally online, but targeting the wrong device, using the wrong filesystem tool, or discovering a damaged filesystem during the change can still interrupt the workload.

  4. Grow the filesystem with resize2fs when FSTYPE is ext4. 
    $ sudo resize2fs /dev/vgdata/data
resize2fs 1.47.2 (1-Jan-2025)
Filesystem at /dev/vgdata/data is mounted on /srv/data; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vgdata/data is now 262144 (4k) blocks long.

    Omitting the size tells resize2fs to fill the available logical-volume space. The command resizes ext2, ext3, and ext4 filesystems, but it does not expand the underlying LV.

  5. Grow the filesystem with xfs_growfs when FSTYPE is xfs. 
    $ sudo xfs_growfs /srv/data
meta-data=/dev/mapper/vgdata-data isize=512    agcount=4, agsize=32768 blks
data     =                       bsize=4096   blocks=131072, imaxpct=25
##### snipped #####
data blocks changed from 131072 to 196608

    Run either the ext4 step or the XFS step for this mount, not both. xfs_growfs targets the mounted path, such as /srv/data, instead of the LV device path.

  6. Verify that the mounted path reports the larger capacity. 
    $ df -h /srv/data
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/vgdata-data    991M  152K  935M   1% /srv/data

    If df still reports the old size, recheck the FSTYPE value, confirm the LV is larger, and make sure the grow command targeted the active mounted filesystem.