Resize an ext4 Filesystem Safely with resize2fs

resize2fs enlarges or shrinks an ext2, ext3 or ext4 filesystem while the partition or logical volume boundary stays exactly where you left it. Allow 15 to 30 minutes for a small test or a straightforward enlargement, and longer for a large offline filesystem.

A shrink needs more planning than a grow, because the filesystem must be reduced before its container is. This guide describes the installed resize2fs from e2fsprogs 1.47.0, released on 5 February 2023. You need root access for device inspection and most real resize operations, a current backup, and a maintenance window for an offline change. Do not practise these commands on a valuable device.

1. Identify the filesystem and its container

Start by finding the exact block device, filesystem type, mount point and container size. Do not infer a device name from a tutorial or from the order of disks in a machine.

$ findmnt -t ext2,ext3,ext4
$ lsblk -o NAME,PATH,FSTYPE,SIZE,MOUNTPOINTS
$ sudo blkid /dev/DEVICE

Replace /dev/DEVICE with the complete device, such as /dev/mapper/vg_data-lv_archive or /dev/sdb1. The target must be an ext2, ext3 or ext4 filesystem: resize2fs changes the filesystem inside a device, it does not resize a partition, physical volume or logical volume.

Checkpoint: write down the target path, current size, filesystem type and mount point. If findmnt shows the filesystem is mounted, treat an enlargement as an online operation only when the kernel and filesystem support it. A shrink must be offline.

2. Record a recovery point

Check that the backup can actually be read before you change anything. A snapshot can help with a logical volume, but it is not a substitute for a separate backup: a storage failure can destroy both the origin and its snapshot.

Warning: there is no general undo command for a completed resize. The -z option can write overwritten blocks to an undo file for use with e2undo, but the manual warns that it cannot recover from a power or system crash. Keep a verified backup and arrange console access before proceeding.

3. Check the filesystem before an offline resize

Unmount the target before shrinking it, or before any operation that needs an offline filesystem. If it is the root filesystem, boot a suitable rescue or live environment instead of trying to unmount the running root.

$ sudo umount /dev/DEVICE
$ sudo e2fsck -f /dev/DEVICE

Do not continue if e2fsck reports unresolved errors. Follow its repair prompts only when you have a backup and understand the recovery implications. Confirm the state before resizing:

$ findmnt /dev/DEVICE || true
$ sudo dumpe2fs -h /dev/DEVICE | grep -E 'Block size|Block count|Filesystem features'

An empty findmnt result means the device is not currently mounted. The header output gives you the block size and block count to compare with your planned size. The command needs elevated privileges because filesystem metadata is being read from a block device.

4. Enlarge the containing device first

For an enlargement, extend the container first. With LVM, that usually means extending the logical volume; with a partition, it must already extend farther while keeping its original start sector. A partition-table edit is high risk: choosing a different starting point can destroy the filesystem. Use your normal LVM or partition-management procedure and verify the resulting device size before running resize2fs.

$ sudo lvs -o lv_path,lv_size,vg_name /dev/vg_data/lv_archive
$ sudo lvextend -L +20G /dev/vg_data/lv_archive
$ sudo blockdev --getsize64 /dev/mapper/vg_data-lv_archive

In this example, lvextend changes the logical volume and requires root. The +20G form adds space, so do not use it unless the additional space is available and intended. If the LVM command succeeds, the final command reports the new byte capacity: it does not resize the filesystem.

Checkpoint: if the container did not grow, stop. resize2fs cannot make a filesystem larger than its device, and forcing it is not a repair.

5. Grow the filesystem to the available boundary

With the containing device enlarged, omit the size to use the full device. An ext3 or ext4 filesystem can usually be grown while mounted when online resizing is supported, but an unmounted operation is easier to reason about during planned maintenance.

$ sudo resize2fs -p /dev/DEVICE

The -p option requests progress bars for a non-trivial offline resize; very fast operations may show no bar. For a mounted filesystem, use the same command only after confirming the installed kernel and filesystem support online growth:

$ sudo resize2fs /dev/DEVICE

Expected output varies with the filesystem and workload. The useful success signal is a zero exit status followed by a size check, not a particular percentage line:

$ printf 'resize status: %s\n' "$?"
resize status: 0
$ sudo dumpe2fs -h /dev/DEVICE | grep -E 'Block count|Filesystem features'

If the filesystem was unmounted, mount it again and check the available space:

$ sudo mount /dev/DEVICE /MOUNT_POINT
$ df -hT /MOUNT_POINT

6. Shrink in the safe order

A shrink is destructive if the target is too small for the data. Choose a size with headroom first, then unmount and check the filesystem. Only after resize2fs finishes may you reduce the partition or logical volume: reducing the container first cuts off filesystem blocks and can make recovery impossible.

$ sudo umount /dev/DEVICE
$ sudo e2fsck -f /dev/DEVICE
$ sudo resize2fs -p /dev/DEVICE 80G

The 80G value is an example, not a recommendation. Units are binary: G means a power-of-two gigabyte, an unsuffixed number means filesystem blocks, and s means 512-byte sectors. Choose a size above the used data and verify the command's result before changing the container.

When the filesystem resize succeeds, check its new block count and then reduce the LVM logical volume or partition to at least that size. Keep the filesystem and container aligned: a little container headroom is safer than a container smaller than the filesystem.

$ sudo dumpe2fs -h /dev/DEVICE | grep -E 'Block size|Block count'
$ sudo lvreduce -L 80G /dev/vg_data/lv_archive
$ sudo e2fsck -f /dev/DEVICE
$ sudo mount /dev/DEVICE /MOUNT_POINT

Warning: lvreduce is an irreversible storage change and needs root. Do not run it until the filesystem size has been independently checked. If the filesystem resize fails, do not reduce the container; restore the backup or investigate while the original boundary remains intact.

7. Use diagnostic options only for a reason

-M asks resize2fs to shrink the filesystem to the smallest size it can estimate from the stored files. The manual says this estimate may be incorrect, especially with 1K and 2K block sizes, so treat it as an input to planning rather than a magic safe minimum. -P prints an estimate and exits without performing the shrink.

$ sudo resize2fs -P /dev/DEVICE
$ sudo resize2fs -M -p /dev/DEVICE

-f overrides some safety checks. It does not make an unsafe target safe, so leave it out unless a specific, understood check is blocking a reviewed operation. The -b and -s options enable or disable the ext4 64-bit feature and cannot be combined with a resize in the same operation.

Done means