How to Increase the Size of an ext2, ext3 or ext4 Filesystem on Linux Systems

Objective

To increase the size of an ext2, ext3 or ext4 filesystem so as to completely fill a block device

Background

Increasing the usable capacity of a filesystem on a resizeable block device (such as a partition or logical volume) is a two-step process:

1. Increase the size of the block device.
2. Increase the size of the filesystem to fill the block device.

The method for the first step depends on the type of block device, and the method for the second step depends on the type of filesystem. These instructions cover step 2 in the case where the filesystem is ext2, ext3 or ext4.

Scenario

Suppose that /dev/vg0/foo was originally an 80GB logical volume containing an ext3 filesystem. You have used the lvextend command to increase the size of the logical volume to 120GB, but you are not yet able to use this extra space because the filesystem remains formatted for 80GB. You want to make the extra 40GB usable.

(The method described here is not specific to LVM, and could be usefully applied to any block device that can be resized without destroying its contents.)

Method

Overview

Resizing is performed using the resize2fs command, however there are some preparatory steps that you can take which will reduce the risk of data loss:

1. Ensure that you have an up to date backup.
2. Unmount the filesystem.
3. Check the filesystem.

(In older documentation you may encounter references to the programs ext2resize and ext2online. These are now obsolete and should not normally be used.)

Ensure that you have an up to date backup of the filesystem

Extending a filesystem is a moderately high-risk operation, so if you take backups of the data at all then this is a good time to perform one.

Optionally, unmount the filesystem

Modern versions of the Linux kernel can expand an ext3 or ext4 filesystem while it is mounted. This has obvious benefits, but provides significantly more opportunity for things to go wrong. For this reason it would be prudent to unmount the filesystem before resizing it unless there is a good reason not to:

umount /dev/vg0/foo

At the time of writing, current (2.6-series) kernels did not support online resizing of ext2 filesystems. Unmounting is therefore essential in that case.

Check the filesystem

One factor that would increase the risk of failure is if there are pre-existing errors in the filesystem. For non-mounted filesystems, this risk can be reduced by checking the filesystem before resizing it:

fsck -f /dev/vg0/foo

resize2fs will refuse to run if it thinks the filesystem ought to be checked first, however there is no harm in running fsck regardless provided that you are confident the filesystem is not mounted.

For mounted filesystems you should definitely not do this, otherwise fsck may itself cause data loss.

Resize the filesystem

Use the resize2fs command to resize the filesystem:

resize2fs /dev/vg0/foo

You can specify the required final size of the filesystem, but there is no need to in this instance because it defaults to the size of the device. The command is the same whether or not the filesystem is mounted.

The amount of time taken by resize2fs to enlarge a filesystem is broadly comparable to that taken by mkfs to create a new one. The example described here took about a minute during testing, but this will obviously vary with the speed of the hardware. The amount of data in the filesystem does not greatly affect the time taken.

You can request a progress bar using the -p option. This appears to work when resizing offline, but not when resizing online.

When resize2fs has finished it should report the new size of the filesystem in blocks:

The filesystem on /dev/vg0/foo is now 31457280 blocks long.

Note that resize2fs does not change the block size, even if a freshly created filesystem on the same device would default to a larger size. For this reason, recreation may be a better option if you need to turn a very small filesystem into a very large one.

Testing

You can obtain an approximate value for the new size of the filesystem using the df command once it has been remounted. The output should be similar to the following:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg0-foo  123854820    192188 117371688   1% /mnt

The number of 1k blocks reported (123854820 in this case) is slightly less than the full size of the device (125829120). This is normal. If you want to see the exact size, or do not want to mount the filesystem, then you can use the dumpe2fs command:

dumpe2fs -h /dev/vg0/foo

The output is quite lengthy, but should contain the following information:

Inode count:              7864320
Block count:              31457280
Reserved block count:     1572736
Free blocks:              30915658
Free inodes:              7864309
First block:              0
Block size:               4096
Fragment size:            4096

The block count should be the same as the value reported by resize2fs. The size in bytes is the block count multiplied by the block size.