Resize an LVM Logical Volume Without Guessing the New Size

You will resize an LVM logical volume with lvresize, optionally resize the filesystem on it, and verify both layers afterwards. Allow 10 to 20 minutes for a straightforward extension, longer if you need to investigate free extents, filesystem support or a busy service. The examples use vgdata/lvfiles as a placeholder. Replace it with the real volume only after checking it.

This guide describes the installed LVM 2.03.16(2) command, dated 18 May 2022. The machine used for these checks cannot access its device-mapper kernel driver as an unprivileged user, so the examples are syntax-checked rather than run against a real volume. Run state-changing commands with sudo or as root, and keep a tested backup before reducing anything.

1. Check the command and identify the volume

Start by confirming the binary and version. These checks do not change storage:

$ command -v lvresize
/usr/sbin/lvresize
$ lvresize --version
  LVM version:     2.03.16(2) (2022-05-18)

List the logical volumes, their sizes and their backing devices:

$ sudo lvs --all --options vg_name,lv_name,lv_size,lv_attr,lv_path
  VG     LV      LSize  Attr       Path
  vgdata lvfiles  20.00g -wi-ao---- /dev/vgdata/lvfiles

Check the filesystem separately. The mount point tells you which live service could be affected:

$ findmnt --source /dev/vgdata/lvfiles
TARGET  SOURCE                 FSTYPE OPTIONS
/srv    /dev/mapper/vgdata-lvfiles xfs   rw,relatime

Do not infer the filesystem from the LV name. If findmnt returns no row, the volume may be unmounted, inactive or not the path you intended. Stop at this checkpoint and resolve that ambiguity first.

2. Confirm free space in the volume group

An extension needs free physical extents in the volume group, unless you also add storage through a separate LVM operation. Inspect the free space:

$ sudo vgs --options vg_name,vg_size,vg_free
  VG     VSize   VFree
  vgdata 100.00g  30.00g

Size arguments use binary units: G means GiB and M means MiB, regardless of capitalisation. -L 30G means a new total size of 30 GiB. -L +10G means add 10 GiB to the current size. The plus and minus prefixes are the easiest place to make a damaging mistake, so say the intended total size aloud before pressing Enter.

3. Extend the LV to an absolute size

For the least ambiguous change, specify the desired final size. The following grows the LV from 20 GiB to 30 GiB:

$ sudo lvresize --size 30G vgdata/lvfiles
  Size of logical volume vgdata/lvfiles changed from 20.00 GiB (5120 extents) to 30.00 GiB (7680 extents).
  Logical volume vgdata/lvfiles successfully resized.

The command changes the block device, not necessarily the filesystem inside it. For an online filesystem extension, request both operations explicitly with --resizefs:

$ sudo lvresize --resizefs --size 30G vgdata/lvfiles

--resizefs delegates filesystem work to fsadm. Its support and safety checks depend on the filesystem and the installed tools. Read the command output and check the mount state before using it on a service volume. A filesystem that does not support the required online operation may need a maintenance window and a filesystem-specific procedure.

4. Use relative or percentage sizing deliberately

A relative size is useful when the current size is known and the requested change is small:

$ sudo lvresize --resizefs --size +10G vgdata/lvfiles

To allocate half of the volume group's size as the new LV limit, use logical extents and the %VG suffix:

$ sudo lvresize --size 50%VG vgdata/lvfiles

Percentages describe a limit for the new logical extent count, not a promise that every last byte will be usable. The exact count is resolved during the operation. %FREE refers to remaining free space in the volume group, while %PVS refers to free space on the physical volumes named on the command line. Use %FREE only when 'consume the available VG space' is genuinely the goal.

The alternative --extents option expresses the new size in logical extents. It is useful when your storage layout is managed in extents or when a percentage is more appropriate than a byte size:

$ sudo lvresize --extents 7680 vgdata/lvfiles

--size and --extents are alternate ways to specify the LV size. Do not supply both for one resize.

5. Restrict allocation only when you understand the layout

You can provide physical volumes after the LV to constrain where new extents are allocated. This is a placement decision, not a filesystem option:

$ sudo lvresize --size +16M vgdata/lvfiles /dev/sda:0-1 /dev/sdb:0-1

The ranges above are physical extent ranges. They are examples only: use them only after inspecting the actual PVs and layout. LVM's normal allocation policy avoids unsuitable placements, while --alloc anywhere can accept placements that reduce performance, such as putting stripes on the same PV. Do not add allocation overrides to make an unexplained failure disappear.

6. Verify both the block device and filesystem

After an extension, inspect the LV and the filesystem independently:

$ sudo lvs --options lv_path,lv_size,lv_attr vgdata/lvfiles
  LV Path                 LSize  Attr
  /dev/vgdata/lvfiles     30.00g -wi-ao----
$ df -hT /srv
Filesystem                 Type  Size  Used Avail Use% Mounted on
/dev/mapper/vgdata-lvfiles xfs    30G   12G   18G  40% /srv

If lvs shows the new size but df still shows the old filesystem size, the LV extension succeeded and the filesystem step did not. Do not repeat the LV extension. Consult the filesystem's own resize tool and procedure, preserving the exact device and mount point.

Keep LVM metadata backups enabled. The default is to create an automatic metadata backup after a change, and the manual strongly recommends this. Check that the backup directory contains a recent volume-group backup according to your distribution's LVM configuration.

7. Treat reductions as a separate, destructive operation

Adding space is usually recoverable from the original data. Removing space is not. Never run a command such as lvresize --size 15G vgdata/lvfiles against a 30 GiB filesystem just because the LV command accepts the number. The filesystem must be reduced first, using a filesystem-specific offline procedure where required, and its final size must fit inside the proposed LV.

Before reducing anything, stop the service, unmount the filesystem when the filesystem procedure requires it, take and test a backup, and record a rollback plan. If the new layout is wrong, the practical recovery is usually restoring the data into a correctly sized volume, not reversing the LV command. Do not use --force or --yes to bypass a warning unless you have already established why the warning is safe to override. --test can suppress metadata writes, but it still reports success in ways that can be misleading during multi-stage operations, so treat it as a planning aid rather than proof that a real resize will work.