Safely Extend an LVM Logical Volume with lvextend

lvextend grows an existing LVM logical volume and, where supported, its filesystem too. You will finish with a larger volume and, where supported, a filesystem enlarged to match it. This guide uses the installed lvm2 2.03.16 tools, package version 2.03.16-3ubuntu3.2. Allow about fifteen minutes for a straightforward online resize, plus time for a backup and service checks.

The examples assume an existing volume group called vg01 and logical volume data. Replace both names with values from your host. Extending an LV allocates free physical extents from a volume group. It cannot create free space by itself, and it does not automatically make every filesystem larger.

Warning: This changes storage metadata and may change a mounted filesystem. Confirm the target, keep a current backup, and arrange a maintenance window if the service or filesystem requires one. Never use --force or --yes to silence a warning you have not understood.

1. Confirm the tool and identify the target

Check the installed version first. This is read-only and does not need elevated privileges:

$ lvextend --version
  LVM version:     2.03.16(2) (2022-05-18)
$ dpkg-query -W -f='${Package} ${Version}\n' lvm2
lvm2 2.03.16-3ubuntu3.2

The exact build and output formatting can differ on another distribution. The command syntax below follows the local 2.03.16 manual. Use the complete LV name, normally VG/LV, so the operation cannot accidentally select a similarly named volume in another group.

Checkpoint: list the volume groups and logical volumes, then record the current size and free space:

$ vgs
$ lvs -o vg_name,lv_name,lv_size,lv_attr
  VG   LV    LSize  Attr
  vg01 data  20.00g -wi-ao----

The sample row is illustrative: your output is the authority. If VFree in vgs is smaller than the requested increase, stop and investigate the volume group or add capacity through a separate, planned storage operation.

2. Check the filesystem and free extents

Find what is mounted from the LV and whether the filesystem has room to grow. These checks are ordinary commands:

$ findmnt --source /dev/mapper/vg01-data
$ df -hT /path/to/mount

Replace /path/to/mount with the actual mount point. Do not assume that the LV name identifies the filesystem, or that the filesystem can be resized while mounted. lvextend --resizefs, also written -r, asks fsadm to resize the underlying filesystem with the LV. That is convenient for supported filesystems, but it is an additional operation with its own checks and failure modes.

For a filesystem or storage stack that fsadm does not support, extend the LV only after you have a filesystem-specific resize procedure. A larger block device is not the same thing as a larger filesystem. If you cannot state how the filesystem will be resized and verified, stop here.

3. Preview the allocation

Use test mode to exercise LVM's checks without writing metadata:

$ sudo lvextend --test --size +5G vg01/data

--test disables metadata writing and may still report unusual messages during a multi-stage operation. A successful test is useful evidence that the requested allocation can be planned, not proof that the real command will succeed. It does not resize the LV or its filesystem.

Do not add --resizefs to this preview and then infer that a filesystem resize has happened. The real filesystem operation belongs to the non-test command in the next step.

4. Extend by an explicit amount

After checking the preview, extend the LV by a relative amount. This requires elevated privileges:

$ sudo lvextend --size +5G vg01/data
  Size of logical volume vg01/data changed from 20.00 GiB (5120 extents) to 25.00 GiB (6400 extents).
  Logical volume vg01/data successfully resized.

The output numbers depend on the extent size and current LV. The leading + matters: --size 25G requests a new total size, while --size +5G adds 5 GiB to the current size. LVM input units are binary values, so the local manual treats G as GiB. This is a common source of surprisingly precise-looking sizes.

If the command fails because the volume group has insufficient free extents, no successful resize should be assumed. Re-run vgs and lvs rather than repeatedly adding options. Do not use --alloc anywhere as a first response: it can place parallel stripes on the same physical volume and reduce performance.

5. Resize the filesystem when appropriate

If the filesystem is supported by fsadm and your maintenance plan allows it, the combined form performs the LV and filesystem work together:

$ sudo lvextend --resizefs --size +5G vg01/data
  Size of logical volume vg01/data changed ...
  Logical volume vg01/data successfully resized.

Do not run this combined command after the standalone command in step 4 unless you deliberately want to add another 5G. Choose one path. If step 4 has already enlarged the LV, follow the filesystem's documented grow procedure and verify it before changing anything else.

There is no general shrink or undo equivalent here. Restoring the old LV size would require a filesystem-aware shrink sequence, and many filesystems cannot be shrunk at all. If you extended the wrong LV, stop writes, preserve evidence, and recover from your backup or a carefully planned migration. Do not try lvreduce against a mounted filesystem.

6. Verify both layers

Check the block device and filesystem separately:

$ sudo lvs -o vg_name,lv_name,lv_size,lv_attr vg01/data
$ df -hT /path/to/mount
$ findmnt --source /dev/mapper/vg01-data

The LV size should show the new capacity. The filesystem size should also be larger when you used --resizefs or completed a filesystem-specific grow operation. If the LV grew but df did not, do not repeat lvextend; the missing step is filesystem resizing. If a mounted service reports errors, stop the service according to its operational procedure and inspect its logs before attempting more storage changes.

LVM normally creates an automatic metadata backup after a change, and the manual strongly advises keeping that behaviour enabled. Check your backup policy and retain the relevant metadata backup with the rest of the change record. That backup is useful for LVM metadata recovery, but it is not a substitute for a filesystem or application backup.

7. Use free space percentages only when the intent is clear

To consume all remaining free space in the volume group, the local syntax is:

$ sudo lvextend --extents +100%FREE --resizefs vg01/data

+100%FREE is relative and uses the remaining free extents. The percentage form is calculated at execution time, so do not use it in a script where another process can allocate space between your checks and the command unless that race is acceptable. For a particular physical volume, the manual also supports a positional PV argument or +100%PVS, but constrain allocation to a PV only when you understand the layout and failure implications.

Done means